>>18
Despite the problems regarding exception specifications,
unexpected() and such, exceptions in C++ are rather ok in my opinion. I have never had problems with them, and I think they're particularly well design for their purpose. The feasibility of
exception handling, on the other hand, is another matter, and is not restricted to C++ in any way.
About the type system, C++ offers
typeid and
dynamic_cast when it is necessary, but I agree the language should offer some means of providing some reflection, even compile-time reflection would be very useful (that is, automatically create code from the structure of a
known class). The header chains and preprocessor issues are really the compilation bottleneck in any C++ program, and it is derived from C; however, this problem is greatly alleviated by precompiled headers (which, I agree, are a terrible solution for the problem, but they work nonetheless).
Duplicated template instantiations are not much of a problem in modern compilers with template repository control. And I sincerely don't see much obscurity in the implicit type conversion rules -- there are a few cases, and one quickly grasps them once he becomes familiar with the language.
The major problem with C++, in my opinion, is the toolchain. Many problems you've cited would be much better handled if the compiler did it's job a little better, specially when issuing error messages to the user. The fact that C++ inherits many things from C serves it for good and for bad: the limitations of the C toolchain (over which most C++ compilers are written) cannot cope with the complexity of C++, but I disagree that a language should be written towards compatibility with the toolchain. Compilers could produce a lot of information besides mere object files which would help them to locate symbols, handle template instantiations and much more.