I really think the final nail in C++'s coffin is going to be its refusal to play ball in a polygot world. Most languages let you drop down into C pretty easily but C++'s weird name mangling, exceptions and complex, usually nonstandard ABI makes interfacing with C++ a major PITA. In the days when C++ was used soup-to-nuts this wasn't such a big deal but these days you almost always want some kind of higher level language on top.
Just look at all the contortions WinRT has to go through to expose its APIs versus the clean Foundation/Cocoa layering you see in iOS/OS X for a great example.
+1. My thoughts exactly. One of the factors I reject C++ library for my pet projects is that I can't interface them easily with FFI (LuaJIT, Common Lisp CFFI, Python CTypes, etc.).
And one think that I love about ZeroMQ, is that even being C++ it exposes the stuff with extern "C" and makes life easier. I wish Qt, wxWidgets were easier to expose this way (okay, there is SWIG, or some other tools luabind, etc. - but they produce additional DLL/.so files that are sometimes as big as the library they are wrapping (if not bigger)).
At least with clang/llvm and gcc you now have binary compatibility between two competing compilers.
You can take a .o built with gcc (g++) and link it with a .o generated by clang (clang++) without issues. Same name mangling, same everything. This means that I on my system at least don't care anymore whether the project is built with GCC or with clang and I can use either or for my own projects.
The thing though is that the C++ standard doesn't have a default ABI, so saying that it is non-standard isn't even the case, that we get any compatibility is nice at all, and I understand that complaint.
The biggest issue I've ran into is that even with the same compiler on the same platform (using MSVC 2008) setting different compiler flags generated completely different code and memory layouts for std::vector that caused me to not be able to link against a DLL. At least some consistency exists with other compilers and different flags don't necessarily change compatibility.
I don't think it is entirely fair to compare WinRT with Foundation/Cocoa. WinRT has an entirely different goal than what Foundation/Cocoa provide, and Foundation/Cocoa provide none of the same things that WinRT provides such as a object model that can be used across different programming languages fairly easily. Mac OS X has nothing that even comes close to COM.
Mac OS X has nothing that even comes close to COM.
Because it doesn't need something like COM. As is so often the case, Apple has made some radical simplifications. ObjC has its faults but the C/ObjC/ObjC++ stack covers a lot of ground with minimal mental overhead.