C++ has caused the following problems for the EROS project that are prompting us
to switch the code over to C:
1. Compiler and language evolution
As compilers have converged on actually implementing the language standard, a
number of language features have become mandatory, most notably exceptions. The
problem is that the standard says 'new' can throw an exception, and the compiler
must make the conservative assumption that at some point in your program you
will allocate memory. When we switched to egcs, which supports all of this
gorp, we experienced the following consequences:
+ Total code size (as measured by 'size') grew by a factor of three. Some of
this was inline code growth (i.e. code that actually gets executed), much of
which occurred in critical paths.
+ The runtime suddenly needed to be able to call malloc to allocate the
exception structure.
+ Code cache locality was destroyed, because functions that were previously
placed together were now seperated by the recovery code.
+ The minimal runtime environment suddenly required a lot more stuff.
I eventually found the switches and doodads in egcs to turn all of this crap
off, but that led to a situation where the kernel code was heavily dependent on
the ability of the compiler to selectively and intelligently disable features.
In effect, the code base became tied to the compiler, which for EROS purposes is
undesirable.
The other side of the equation, of course, is to ask what actual benefit we were
getting from C++. It proves that the answer is "damn little." EROS makes no
use of templates or RTTI. Inheritance, where it exists in the kernel, is always
single inheritance and never has an inheritance depth greater than three. For
the morbidly curious, those cases were:
Node : ObjectHeader : KeyRing
and
xxxKey : DiskKey : Key
While we do get stronger type checking, this has proved to be as much a
hindrance as a help. For example, the IDE driver ran into a bunch of places
where you really wanted to have interfaces rather than classes, and it was
unreasonably hard to do this in C++. In particular, there is no way to declare
a pointer to member function generically across class types (there are several
places where you would like to say "member of X taking arg types (int, long),
don't ask what X is."
So anyway, that's the reader's digest synopsis.
Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595
"Bill Kelly" <billk@cts.com> on 07/07/99 07:27:56 AM
To: linux-kernel@vger.rutgers.edu
cc: Jonathan S Shapiro/Watson/IBM@IBMUS
Subject: Re: linux headers and C++
> Chip Salzenberg <chip@perlsupport.com> wrote:
>
[...]
> That said, I entirely agree that it's not necessary to use C++ instead
> of C to write good code. On the other hand, I suggest that C++ would
> have been a good choice for the Linux kernel __IF__ a compiler of the
> quality of today's EGCS had been available back then. But it wasn't.
I'm inclined to agree that given a good compiler, C++ should be a good
choice for kernel development - except I seem to recall in that operating
system thread we had a couple weeks ago, the EROS people saying they
regretted choosing C++ and planned to reimplement in C.
That statement has been on my mind a lot since then; perhaps one of the EROS
folk would be willing to provide some details?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/