Messages in this thread | | | Subject | Re: C++ in kernel (was Re: exception in a device driver) | Date | Thu, 7 Jan 1999 02:06:25 -0600 (EST) | From | kwrohrer@ce ... |
| |
And lo, Benjamin Scherrey saith unto me: > Anthony Barbachan wrote: > > There's also usually a huge amount of overhead associated with C++ > > exceptions, probably not a good idea for a Linux driver. Furthermore the > > simpliar method of checking the returned value(s) of functions is also > > easier to understand, read, and debug. > > A huge amount compared to what? C++ exception handling is not just a fancy > replacement for checking return values. It allows an expressiveness and more > flexible flow of control within the code that may have to deal with that > situation. Used properly, exception handling should result in little or not > overhead compared to the explicitly coded option and sometimes can result in > less overhead. I've seen this happen in several situations when a well > organized exception handling policy was present. Lots of code that had to check > for error conditions simply went away. Assuming you perfectly understood how each exceptional error is/should be handled and at which levels, even assuming you only used exceptions for serious problems that are designed to be handled at a significantly higher level than the caller, you still have the try/catch blocks added all over functions through which exceptions are thrown, undoing attempted actions (assuming it can know for sure if they succeeded, and assuming the partial actions can be undone), and mopping up all the dynamic data and changes to static data (the OO philosophy of "that's what stack unwinding and destructors are for" doesn't fly well with the kernel stack size limitations I recall...).
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/
| |