[linux-elitists] Nobody's favorite language? C++ and free software

Aaron Sherman ajs@ajs.com
Wed Mar 26 08:30:27 PST 2003

On Tue, 2003-03-25 at 14:25, Don Marti wrote:

> My question is -- now that we have GCC 3.2.x and an increasing
> collection of interesting free software using C++, is it time to
> take a second look at this perhaps unfairly maligned language?

Yes it is (time), and no it's not (unfairly maligned).

> A good example is this late 2000 Advogato thread, which covered
> some key objections to C++ among free software developers:
> http://www.advogato.org/article/207.html
> I've tried to list a few from that thread, this list, and other
> sources.
> 1. Everybody knows C, few people know all of C++.

True, but that could change. It could also change in favor of Java, C#,
Perl, Python, Ruby, Scheme or 6502 assembly, so unless you're asking
this question because you need to walk out the door and recruit 200
people today, it's not much of an issue.

> 2. C++ is a Very Large Language
>   K&R, The C Programming Language, 2nd ed. -- 274pp.
>   Stroustrup, The C++ Programming Language, 3rd Special Ed. -- 1040pp.
> "It seems to me quite plausible that the complexity of the language adds
> to the time and cost of a full education in C++." -- Raph Levien

This is a context-free comparison, and thus not terribly valuable. C
provides only the most basic programming tools (in fact, unless you're
using something like glib or an equivalent library, I'm not sure that I
really count C as a modern language which you can use to compare to C++
at all).

What C++ has to be measured in terms of is its price/performance. The
price is complexity. The performance is the flexibility and
functionality given to the developer.

In that sense, I think C++ measures up poorly to high-level languages
and low-level language alike. I've often said that C++ represents all of
the power of a high level language combined with all of the
debuggability of APL. That isn't strictly true, because C++'s
data-structure transformation capabilities are very limited, and it
doesn't have many other high-level features, e.g. lexical closures.

> 3. Unstable C++ ABI in late g++ 2.9.x, early 3.x

This is a major problem, and when it finally settles out, it will be a
huge win for C++. I'll give it a few years to see....

> 4. Some compilers still don't support ISO standard C++, so
> real-world projects end up falling back to a conservative but
> ugly subset that doesn't offer compelling advantages over C.
> (see, for example http://www.mozilla.org/hacking/portable-cpp.html)

A minor issue, when you have gcc everywhere. Getting gcc to support
these standards was crucial.

> 5. GNU tools are slower at building C++ projects than those in C.

"slower"? In what way? I'll have to go read the thread you referenced...

> 6. Binaries are "huge."

Yes, but that's the cost of using a high-level language. Again, see the
section above on trade-offs and why C++ loses.

> 7. C++, because of its corporate success, is associated with non-fun
> projects.

Again, ignorable.

> 8. Not enough beautiful free C++ code to set a good example, while
> there's lots of beautiful C.

There's plenty of beautiful C++. The problem is that all of it starts
off by throwing away huge chunks of the language which impede or at
least de-incentivize good programming practices.

All that said, I'm a Perl user, so my bias it toward the power that a
language gives you, and not on the complexity introduced along the way.

More information about the linux-elitists mailing list