OSNews

This was even more the case when OO was all the rage, and developers went on designing deep class hierarchies just because they could.

This leading to the banana/gorilla problem.

For our embedded (bare metal) development, I have considered OCaml, Ada, Oberon, Pascal, then C++. In that order.

We ended up with C++, because the others failed us with big runtimes, complex cross compiling settings, and lack of host OS support (as in Linux, macosx, Windows etc) which was important since we don't want to force an OS on the developers.
Control over memory allocation is hugely important too - our initial platform only has 32k of ram.

C++ did the job nicely, we have our own templated OS and drivers, and the result is small and efficient.
The only restriction is no RTTI and exceptions, because of the associated runtime.
If we get the opportunity, we'll add the cxa_* funtions to our libraries so we can support exceptions.

So yes, C++ is a good workhorse. We just have to have very experienced developers who know how it works under the hood.

I just wish we had the time to participate in the OCaml or Ada efforts so that cross compiling is as easy as in C++.

Hm? What's that supposed to mean?

This is an extremely strong disadvantage in the context of what ESR is saying: open source programming. It is true that you can alleviate the over complexity of the language in a strongly controlled environment, with one coding style, the do and don't. But in open source programming, this becomes an almost fatal flaw. Only really big projects can deal with C++ (KDE, mozilla).

Also, C++ does not tend well to code reuse; this is linked to the previous point , since it id difficult to reuse the code using one subset in a project using another one. It is difficult as hell to interface to other languages because of its complicated linking model, templates can't be used either as a library without a lot of boilerplate. It is true that STL-like containers are useful, but it comes at such a high price that I am not so sure anymore a plain C library is not better in most cases. "

See the bolded text: this is true if you have developers that can't wrap their heads around designing things for code reuse, and false for those that can. As to the linking model, it's not so bad if you use C++ static functions and straight C interface wrappers (if needed) because C++ static functions use C style linkage, which is as close to universal as you'll find overall. But, if you don't know how to deal with that, then yes, it becomes a mess. Again, for code reuse, that's very much a function (pardon the pun) of the design method (there's another one!) of the developer and what attributes they use in their designs: if you try to use all the fancy features and make an overly complicated class hierarchy with multiple inheritance where each class in a hierarchy depends on other classes that depend on it (creating cyclic dependencies) then yes, that highly hinders code-reuse. Then again, there's absolutely nothing in straight C that prevents you from screwing things up in the same manner, and for that matter, any language that allows you to use forward declarations is not immune to this (which most do as a practical matter): this is a limit of the developers using the language, and not the language itself. Spaghetti C++ code is just more obvious to see than spaghetti straight C code, but there's more than enough snarled straight C code (as well as Java, Perl, etc.) to show it is hardly a C++ism that's unique to the language.