[Strom]

There are superior languages out there that do a better job

Your statement is false, because the choice of language depends on the job. For example, when I need to make something simple quickly I will do it in C#. However when I need to write an add-on to an existing application that doesn't have an official plugin system, then C++ and Assembly are really awesome.

[loup-vaillant]

It seems you missed his qualifier: "for building complicated software that is robust, easy to use, easy to maintain, fast and scalable"

Complicated + robust + easy to maintain is plain impossible in C++. Also, add-ons fit "enhance software" better than "building software".

[Strom]

Complicated + robust + easy to maintain is plain impossible in C++. I don't think so.

Also, add-ons fit "enhance software" better than "building software". Your "building software" could also be labeled as enhancing the operating system.

[loup-vaillant]

(1) Okay, let's speculate about the actual requirements for robust, easy to maintain software. Robust means it won't fail easily. A robust program handles edge cases correctly, and have few errors. An easy to maintain program is one that is easy to correct or modify. To achieve this, you must make it so that most modifications require the inspection of relatively few code. It means the code base must be either small or very well de-coupled.

Now let's add "complicated". To me, it means the problem cannot be solved by a small program. Therefore, the program will be rather big. To achieve robustness and ease of maintenance, you have to make it locally readable and modular.

Now, add "in C++". C++ is extremely permissive. You can tweak almost anything. It can be awesome, but there is a flip side: memory must be handled manually (more code), and you can make fewer assumptions about your program (less modular code). For an originally complicated problem, this is a significant burden.

Now, a very disciplined team could overcome this burden. Just mind a few things: Const correctness everywhere, and avoid side effects where you can (this is both extremely important[1] and not easy in C++[2]). Ban or restrict the use of the more problematic features (I would mostly scrap inheritance, except when emulating Java interfaces). Use the remaining features in a standardized manner (make sure copy constructors and destructors are correct, use initialization lists systematically or not at all, make everything exception-safe or ban exceptions, use std::auto_ptr<> as much as possible, and probably a gazillion other crucial things I forgot).

Some individuals are indeed that disciplined. But an entire team? Good luck finding it.

(2) The API of most operating systems are sufficiently language independent to allow several languages. Most languages are sufficiently OS independent to allow the port of programs in several operating systems. This is basically because an OS API and standard libraries are effectively the two halves of a plug-in system.

So, the constraints are very unlike those you find when adding functionality to a program which doesn't have any plug-in system. I concede that C and C++, as the default API for current operating systems, are favoured. But the burden on other languages is barely noticeable (except maybe for the language implementer).

[1]: http://www.loup-vaillant.fr/articles/assignment

[2]: http://www.loup-vaillant.fr/tutorials/avoid-assignment

[maeon3]

There are times when it is appropriate to select C/C++ for the job, that is when enhancing a project written in C++.