Yes, "More Effective C++" is definitely worthwhile.
You may also want to take a look here:
Apparently so, though in the book I have Scott Meyers & John M. Vlissides on wrote the foreword.
This book was an eyeopener to me that C++ templates could be used for much, much more than generic containers of type T and generic functions. However I haven't found much use for the techniques presented in this book simply because they are way beyond the knowledge of the average C++ programmer, and frankly at times also beyond my understanding of C++ (which I was taught in 1992, and I have used it for the majority of projects I have done since 1995 so I do consider my knowledge of C++ a bit above average). Since the code I'm responsible for needs to be maintained by people that are not necessarily C++ gurus, the 'understandability' of code is an important concern for me.
The skill of the programmer is very important with C++, more so than with simpler programming languages (such as C) or a more restrictive programming languages (such as Java).
Templates can be great for generic libraries (e.g. the boost library), and do not necessarily create code bloat (though easily can when one is not careful). However writing a good and efficient templated C++ library requires a lot of skill and know-how. It helps a lot if one has a mental picture how the compiler works. My experience is that this can be expected only from a very few C++ programmers.
Advances in compiler technology means that some advise with respect to efficiency that was good a decade ago is poor advise today. I still regularly have to demonstrate to people that ugly hacks that they think are more efficient than well written (straightforward) code actually aren't more efficient with modern compilers and at times even less efficient.
On the other hand with return values it is all to easy to ignore return codes that indicate an error. Also propagating an error from the point where it is detected to the point where it handled involves typically a lot of code that really doesn't improve the overall clarity. It is tempting for many programmer just 'forget' to handle that unlikely failure scenario.
It is unfortunate that the C++ exception specification is worse than useless and is best avoided. In Java exception specifications are mandatory and enforced at compile time, so it is instantly obvious for the caller what kind of exceptions to expect. It would be nice to have something similar in C++, rather than the current runtime check of the exception specification.
On the other hand just muddling along with invalid data can have disastrous consequences as well. I have worked on systems where the software is actually deliberately stopped as soon as a pre- or postcondition violation is detected, just to prevent from failures go unnoticed and causing more costly (and difficult to analyze) problems later.
It depends very much on the kind of application which behavior is more desirable.
Exceptions can be implemented by the compiler in various ways, with some implementations the runtime overhead is zero as long as no exceptions are thrown, at the expense of more runtime overhead when exceptions are thrown. However when every byte counts exceptions are not a good choice.
True, but this applies to most features in C++. Are exceptions good or bad? As with most things it is a trade-off and the only right answer is: "it depends".
Agreed.