Messages in this thread | | | Date | Tue, 05 Jan 1999 20:57:47 -0500 | From | Benjamin Scherrey <> | Subject | C++ in kernel (was Re: exception in a device driver) |
| |
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. 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.
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 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.
Until then, its time to start considering getting the kernel's code buildable by g++ a little at a time. Just using it as a "better C" rather than bringing all its features in at once would make for a cleaner system and extend the life of the code by preventing cod rot. I know that this was attempted briefly a while back (with disastrous results) but the kernel was really out of ANSI spec then and the C++ compilers were not really there. How about evaluating this as a feature for release 2.3?
regards,
Ben Scherrey
PS: I can just feel the cringing from the "C bigots" right now... sorry guys - I really don't mean to stomp your turf!
- 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/
| |