Does g++ even have a warning for throwing an undeclared exception?
> The best part is that most of the
> overhead never had to be paid unless an exception actually did occur. My code
> was smaller and faster as a result. Obviously I completely disagree with your
> last sentence.
But the bloat is still in the kernel, the catches and the throws and the
extra stack unwinding code are all present in RAM...and the "in case
someone writes code that throws sometime in the future, I better clean
everything up" try/catch/throw blocks too.
> Now... what Alan says about the difficulty of supporting it within the
> kernel may very well be the case - I don't know. That said, its time to start
> considering the future. C++ cannot be ignored by the kernel forever. The
> language just offers too much over plain C and was designed specifically with
> large-scale systems programming in mind.
The absolute worst thing you could do to Linux, or any large system, is
to try to rework it into a new design after it's already written. The
second worst is to try to infuse OO-centric syntax and language into it
without a redesign.
> The biggest limitation to full
> adoption of C++ that I've seen is the whole ABI/method call convention/name
> mangling fiasco which I feel really should have been addressed by the ANSI
> committee (at least guidelines and suggestions for future standardization).
> Since the egcs team has started reworking their code for an upcoming "de-facto
> standard", it wouldn't surprise me if more compiler vendors saw the need to at
> least support this as an option. At that point even public interfaces into the
> kernel could be class method calls.
>
Name mangling is not nearly the biggest problem (and if it were, we need
only remember extern "C"...). What *is* the biggest obstacle (not
"problem", mind you) is that the kernel was designed, and is maintained,
by people who know what they're doing and practice good software engineering
techniques like abstraction and data hiding already. They don't need an
OO language to make them fool with an OO design which may or may not lead
them to use some of those techniques; they're already as there as they
will ever be.
Second biggest is how to unwind the stack in the face of an oops or
other notional exception that isn't thrown per se.
Third is modules needing template instantiations the main kernel doesn't,
especially if more than one module needs a given instantiation, double
especially if those modules get out of sync somehow, or someone wants
to ship them in .o format. depmod and modprobe only go so far.
> PS: I can just feel the cringing from the "C bigots" right now... sorry guys -
> I really don't mean to stomp your turf!
The way I see it, OO is a means to an end. We're already there, even
without a pure or semi-pure OO design or language to help. What better
is there to get, that a major upheaval would be worthwhile?
Keith (sorry for that last sentence...)
-- "Well, look at that. The sun's | Linux: http://www.linuxhq.com |"Zooty, coming up." -- John Sheridan, | KDE: http://www.kde.org | zoot "Sleeping in Light", Babylon 5 | Keith: kwrohrer@enteract.com | zoot!" www.midwinter.com/lurk/lurker.html | http://www.enteract.com/~kwrohrer | --Rebo- 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/