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

Alan DuBoff aland@SoftOrchestra.com
Tue Mar 25 11:56:43 PST 2003

On Tuesday 25 March 2003 11:25, Don Marti wrote:
> For example, Xerces and Xalan at apache.org are in C++.

Yes, but Xerces also has a Java implementation also.

> 1. Everybody knows C, few people know all of C++.

Yes, but when C++ was coming to life, Object Oriented Programming was the 
"'thang of the future". C++ was a way to modernize C by adding objects to it. 
It wasn't so much the fact that C++ was the preferred language of the future, 
as much as it was C was the preferred language of the past. C++ merely 
allowed people to reuse existing C frameworks and move forward. Where 
Stroustrup gained advantage was by being able to use existing libraries 
written in C, so nobody had to throw away their old code, or rewrite it.

> 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

Yes, but you still have C, which is a subset of C++, so you loose nothing by 
using it, the C++ compiler will still compiler C code, and the mangling is 
what allows the linkage between C and C++. The mangling is also another area 
that has caused problems in the past, since various vendors implemented their 
own mangling, and there was not a standard implementation.

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

You can blame some of this on the mangling, since it is the mangling that 
defines how the objects in C++ are handled.

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

This is not only GNU where this problem exists. Other tools experience 
similar problems. In many cases the objects are not issolated well and by 
using a class pulls in an entire framework as it's all inherited and/or 
related to each other.

> 6. Binaries are "huge."

Partially, but that is because the object code typically pulls in huge 
libraries which are needed. There is no reason that C++ needs to be huge, it 
just happens that way many times. As an example, look at gtkmm. It's a fairly 
well written framework based on GTK. The programs produced are not real big 
and in many ways refute the "Binaries are huge" argument. 

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

I've had some projects I've worked on over the years that were in C++ and 
were fun. The user interface on the Kerbango Internet Radio was written in 
C++. I wrote a piece for it that used a C libarary to parse XML, store it 
into Standard Template Libraries, and was wrapped in an object oriented front 
end to tie into the UI. That's pretty flexible.

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

I'm not sure I would agree with this. In fact, there is a lot of ugly C code 
floating around.

> My question is -- now that we have GCC 3.2.x
> (http://gcc.gnu.org/gcc-3.2/ -- "A primary objective was to stabilize
> the C++ ABI; we believe that the interface to the compiler and the
> C++ standard library are now relatively stable.") and an increasing
> collection of interesting free software using C++, is it time to
> take a second look at this perhaps unfairly maligned language?

In theory the new C++ ABI will help us use objects produced by various 
compilers, but it doesn't seem to have completed that task quite yet. It 
seems that there are still some obstacles to overcome.

I have always looked at C++ as a tool, just as I do C, and it's good to use 
it for the right solution, just as C, or any other language for that matter. 
I find it better at times to use a piece of ugly Perl code that has a lot of 
features, rather than an elegant piece of Python that has a limited feature 
set in *some* cases. Each case needs to be looked at seperately, and the 
decision between C and C++ is no different than deciding between Perl or 
Python in most cases for me.


Alan DuBoff
Software Orchestration, Inc.
GPG: 1024D/B7A9EBEE 5E00 57CD 5336 5E0B 288B 4126 0D49 0D99 B7A9 EBEE

More information about the linux-elitists mailing list