Yes: GCC has, in fact, been bootstrapped with a C++ compiler, and works the same that way as when compiled with a C compiler. It took some work, but that work has been done.

It arguably leads to more maintainable code, because you get C++'s stronger type checking.

Let's knock those down one at a time.

• From the constructor's initialization list you can call arbitrary functions. Whether you should or not is another matter, but it's certainly possible.
• You can make your constructor take a bool& succeeded parameter if you really can't allow exceptions. (Or even an Error reference.) No worse than C, often better.
• Destructors can and do fail, but if you want to detect failure instead of ignoring it you should call a function explicitly. No worse than C, often better.
• You can indicate in a number of ways that MyClass cannot be inherited from; documentation should suffice, but there is also a silly trick you can use if you think that technical solutions to social problems are a good idea. Even without that, you don't need to allow deletion through the base class; just make its destructor protected.
• If you use resource classes to hold resources (which, it turns out, makes your code cleaner and simpler) then you don't need to do anything about implementing copy operations; the compiler just does the right thing. For your resource classes, you do need to implement them, but there are relatively few such classes, and they're simple.

It is a library for generic algorithms, decoupled from data structures via STL's notion of iterators (which is rather different from GoF iterators). As a proof of concept it happens to provide some containers that work pretty well.

C makes bitwise copies. C++ makes memberwise copies (and in simple cases, can optimize that to a bit copy). In C++ you'd hold a smart pointer, and copying that would do the right thing (whatever the smart pointer defines it to do: ref counting, causing a compilation error, making a copy of the target).

Copy operations in C++ would probably not be implicit, if it weren't for the fact that they're implicit in C.

Different name mangling between different compilers is deliberate, and a good thing: it stops you linking together code that uses incompatible ABIs, and then getting strange crashes.

Now, if you want to complain that it took too long to standardize ABIs for C++, and that it's too hard, and that they're not stable enough, then you might well be able to make a pretty strong case, but that's a different thing. If your ABIs don't match, you shouldn't make your name mangling match.

(Incidentally, if you code in a sane way then the implicit copy operations _almost_ always do the right thing. It would still be better if we had to explicitly enable them, but that would have broken C compatibility, or made struct vs class into two different worlds.)

The ANSI C committee adopted const from C++ in time for the first ANSI C standard, 21 years ago (sadly not calling it "readonly").

(You make a valid point about not having to use every C++ feature to get benefits from using some, and I believe that the plan is to be conservative in introducing features that are helpful while avoiding more controversial or complex features.)

(Reposting, logged in this time.)

If you're using Firefox then this bug is/will be fixed in Firefox 3.6, so that it will report the correct website when things are slow instead of saying "Waiting for *.google-analytics.com. See https://bugzilla.mozilla.org/show_bug.cgi?id=487638 for the details; "status bar blames wrong resource when downloading slow responding resource" is the title of that bug.

If you're using other browser(s), let me know which.

Full disclosure: Google is my employer (and I care about making sure Google Analytics isn't slow).