To be fair, C++ is a mess. It is, however, a very capable mess with extremely broad adoption and compatibility on pretty much every platform anywhere.
Yes, learning C++ is a pain. And it will bite even its expert handlers pretty badly occasionally. But the kind of maintenance overhead suggested by the stackexchange question really isn't there. For non-trivial code (as in the example here) the maintenance and correctness burden of the problem itself is going to be far higher than that of the programming environment.
So yes: just say no to C++ for web server middleware, system maintenance scripting, probably most GUI work, etc... But for the truly hard stuff, I honestly don't see much advantage to anything else in particular. And as pointed out earlier, C++ can be deployed as a straightfoward program or shared library on everything with zero dependencies, and that's a HUGE advantage vs. languages with elaborate runtimes.
"To be fair, C++ is a mess. It is, however, a very capable mess with extremely broad adoption and compatibility on pretty much every platform anywhere."
C++, IMO, is not alone in that: XML, Unicode, multi-threaded programming using condition variables and mutexes, integer modulo arithmetic, date/time libraries, IEEE floating point, etc.
The good thing of all of them is that they solve complex real-world problems. The 'bad' thing is that they are more complex than other technologies that solve the same problem, partly.
I always used to think of compiler design and advanced algorithms as dark magic; however, I now understand that that was just based off of unfamiliarity with the concepts. I suspect that much of that is the same with C++ as well.
I find the cachet that C++ has when you interview for jobs at financial corporations to be equally depressing and hilarious.
When you go in to interview for a C++ position, the guy starts off by looking at you like you're some kind of brain damaged impostor who eats babies when nobody's watching and starts asking about how sizeof works on pointers to member functions or when "inline virtual" does and does not inline something. Essentially, incredibly dick-waving arcane compiler-specific stuff that no one should ever have to know because it makes for really horrible C++ code.
And vice versa when you interview for a Java/C#/Python/whatever position and some of the interviewers drop how they gave up on all that and then look on in admiration when a conversation about actor model drifts into using atomic pointer swapping to build worker queues.
None of it matters, the C++ masochist questions are more an indication of the kind of people you'll be coding with more than anything while the Java/C#/Python/whatever guys are still working on difficult algorithms.
Moral of the story: Since the hardest part of working in C++ is passing the ridiculous interview questions, might as well stick with it to still appear like a wizard. It's all just programming.
C++11 has been finalized for almost two months now! And there's almost one compiler that fully supports it! That's enough time and products for everyone to re-evaluate their experiences with C++!
Seriously, C++, even C++11 is still a mess. Compiler error messages relating to template use -- including the standard library -- are unhelpful at best, except for very recent Clang builds. Compilation time when you actually use what the language has to offer is measured on a geological time scale. The footprint of the generated code, more often than not, makes I-caches cry. You'd be amazed how much faster your computational code runs when it fits properly into an I-cache.
I moved back to plain C a few years ago after having used C++ intensively since '94 or so -- and I'm not looking back. Yes, I do write ~10% more code; it compiles instantaneously, is easier to reason about and to debug, and usually runs just as fast.
I haven't had a chance to try the newfangled C++11 features, but I'd be surprised if they'll make a difference for me.
