1. Exceptions really can reduce the complexity of a large system,
but not the Linux 2.x kernel.
The architecture must be designed/redesigned from the ground up
for exceptions to reduce complexity. Incremental hacks in that
direction will increase complexity. Hence, we must assume that
exception support in the Linux kernel will not happen in 2.x. Like
everything else, Linux will have a successor. That may be written
in C++ or in _its_ successor, and would benefit from exception
handling.
2. Exception resumption is a fraud.
During the ISO Standard Committee debate over C++ exception semantics,
the Microsoft reps were adamant that resumption semantics were
essential. A succession of presentations from people who had tried it
in other languages and OSes demonstrated that the use of it indicated
a conceptual design error. See Stroustrup's "Design and Evolution of
C++" for more info. (Not everybody agrees on this; certainly not MS, who
built it into NT.)
3. Exceptions are implemented efficiently in Egcs.
Exceptions do not add a "huge amount of overhead", or indeed any
net overhead, in a modern implementation. (Though there are reasons
not to use C++ exceptions in the kernel, this is not one of them.)
In fact, systems that use exceptions have been _more_ efficient, as
exception handling replaces the manually-written code to propagate
error codes around. Of course this depends on a modern implementation,
which Egcs has.
4. Binary compatibility will remain a problem for some time.
Egcs currently supports two "name-mangling" schemes, with associated
ABI choices. The default is stable, for now; the "-fnew-abi" ABI has
changed recently and will continue to change probably though this year.
I don't expect to see a "standard" ABI or mangling scheme (de-facto or
otherwise) in the next five years. However, the Egcs "-fnew-abi" ABI
itself will stabilize much sooner, and will be a reasonable basis for
binary compatibility within the Linux milieu probably in 2000. The
effect for C++ libraries and programs will be much like the a.out->ELF
or libc5->libc6 transitions, although of course many fewer programs
will be affected.
None of this ABI instability can have any effect on kernel modules
written in C++, so this is not a reason to resist C++ in modules.
--------
I agree that C++ modules should be supported, but they will need to be
compiled "-fno-exceptions". The only real work needed to enable it is
some cleanup in the headers. I estimate about a month full-time, or less.
If each of two dozen people spent a day on it, it would be done.
Nathan Myers
ncm@cantrip.org
-
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/