[CJefferson]

Where are you getting these ideas from? Who are these C++ zealots you have been listening to? Certainly no-one I talk to.

No-one thinks auto_ptr was a great thing. It was a tool, which could be used with care, but for years most books have said "don't use auto_ptr".

Throw specifications are... throw specifications. Some people like them, over time it has turned out they don't scale too well. Java has gone through a very similar process. I don't get why you were so angry about them.

I don't know why you think anyone thought export was the bee's knees, it's never been available in any of the major compilers since introduction.

In particular, I think everyone agrees export and auto_ptr were bad ideas. That's what literally everyone I hear talk about them says. I don't get why you think these mistakes aren't admitted?

[saurik]

(In a way this is off-topic, but I feel the need to point out that the throws() specifiers in C++ are not like Java's: they are more like a runtime assertion that "if this function throws something not in this set of types, terminate my program"; the result is a situation where you gain nothing at compile time, force an on-some-architectures-painfully-slow exception check on the function, and in the end find yourself with a very similar result to having just not caught the exception at all. This particular C++ feature was sufficiently useless as to be downright harmful. The Java feature, by comparison, has some defensible merit ;P.)

To say something more on-topic: as someone who has been programming in C++ for 15 years, I agree with your comments regarding how C++'a community typically admits the things it sucks at, and is rather pragmatic about the whole thing. (You kind of have to be with a kitchen-sink language like C++ ;P.)

[betterunix]

On the other hand, when I talk about the problems with exceptions in C++, the C++ zealots come out in force. Rather than admit that C++ does exceptions the wrong way, they (a) point to other languages as having the same problem (b) claim that exceptions should not be used in cases where the problems are problems and (c) accuse you of not really understanding what exceptions, destructors, constructors, and object oriented programming are about. Rather than fix the problems with C++ exception in C++11, the standards committee further cemented those problems.

[shawn-butler]

I think you fail to understand what it means to evolve a language specification rather than breaking one.

I think given your obvious bias in both method and approach you should probably just plan on learning a new language every 2-3 years or so when what your ideas of the "best" way to do things changes and languges supporting the latest fad are developed. Probably, just avoid commenting on C++ altogether as it is a waste of your energy because it will quite frankly never do what you want given the aims and goals of the steering committee.

[CJefferson]

Out of interest, what do you feel are the solvable problems with exceptions in C++? The obvious one is exception specifications, which are probably best ignored.

While I agree they are frequently a pain, I'm unaware of any language which has really managed to do exceptions much better. I am happy to hear of examples however.

[betterunix]

Double exception faults come to mind; C++11 did not even attempt to solve this problem, and just sort of brushed it under the rug. The solution to double exception faults is pretty straightforward: the stack should not be unwound until either the end of the exception handler or if the exception handler explicitly unwinds the stack. The downside is that it adds complexity to code generation and some overhead to functions with exception handlers, but the upside is that you have a far more robust exceptions system, and you have an opportunity to add a very nice feature that can help a lot with encapsulation: restarts.

Since you asked for examples, I'll point to the Common Lisp "conditions" system, which includes restarts:

http://www.gigamonkeys.com/book/beyond-exception-handling-co...

(I'll be honest here and point out that "handler-case," while simpler and more convenient, can still have a double exception fault; this is resolved similar to how Java resolves such things, which is to "forget" one of the exceptions. "handler-bind" is slightly less convenient but is much more robust, and does not have this problem.)