A shame

A shame

I think it's sufficient to say that you see design flaws where language designers see design decisions. You may not like the decisions a language designer makes, but that doesn't make them design flaws. Every design decision has tradeoffs, and you make a choice about which tradeoffs you want to work with. A design flaw is when you make a choice without recognizing its short comings. With the exception of exception specifications and ill defined bits in the Java memory model (both of which were the cases where they tried to do something new with unknown implications, rather than borrow concepts that worked well in other languages), I don't think you'll find James Gosling was surprised or disappointed by how things played out.

You've implied with your statements that you think C++ is a "public-standard language that is more powerful and more thoughtfully designed" than Java. Let's look at how it plays out on these issues. Yes, it defaults to non-virtual functions, but it also defaults to private non-virtual inheritence. While most Java code leaves member functions as virtual, most C++ code uses public inheritence and specifies virtual inheritence whenever it is an issue. I'd argue those are issues of style, but if they aren't then I'd have to say C++'s defaults are far more flawed than Java's. C++'s exceptions create so many problems that the people who *worked on the language* couldn't figure out how one would write an exception safe stack for the longest time. C++'s string class can be made to do UCS-32 (you didn't need that memory did you? ;-), but has no notion of using a variable width encoding of strings, and a lot of implementations still ship with 8 and 16-bit character types. Indeed, C++'s string class is so "broken" that there are any number of competing string implementations out there (include C strings) in wide use while Java's String class seems to work just fine for 99% of Java code. C++ claims to be fully compatible with C, but manages to have several subtle differences which turns out to be far more dangerous than being similar enough to help developers understand what they are looking at. C++ is the home of one of the worst macro systems known to mankind and has a powerful templating system who's syntax is so baroque that a number of semantic ambiguities were uncovered at the last minute, forcing some hacked and overloaded uses of the keywords "typename" and "template" to disambiguate the code. Nevermind that the system is so complex to this day few compilers can fully compile code using the likes of boost::lambda. C++ doesn't come with any support for GC, so you end up with people often jury rigging a solution using reference counting that is inherently flawed, increadibly slow and a potential source of deadlocks if you need thread safety, often slower even when single threaded, still leaves them with a fragmented heap and... (wait for it) bad cache interactions.

Despite pointing out all these issues, I like C++, and use it probably more than any other language. The reality is all languages suck, because most design decisions have unfortunate trade offs. It's unfortunate when this intrinsic property distracts from the advantages each language has to offer.