Messages in this thread | | | From | "Anthony Barbachan" <> | Subject | Re: C++ in kernel (was Re: exception in a device driver) | Date | Wed, 6 Jan 1999 04:36:52 -0500 |
| |
-----Original Message----- From: Benjamin Scherrey <scherrey@gte.net> To: Anthony Barbachan <barbacha@Hinako.AMBusiness.com>; linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>; Manfred Spraul <masp0008@stud.uni-sb.de> Date: Tuesday, January 05, 1999 9:14 PM 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.
And in order to get a decent amount of control over the handling of exceptioned errors you end up with a bunch of crap (try { } catch { }) throughout your code adding to its conplexity. And if you decide to centralize error handling with exceptions, you've got a major problem. There's no way to return to the exceptioned statement if you can correct the error and can continue processing (aka, your able to free up some memory within the out of memory exception handler). If this feature was available then this could actually lead to cleaner code, but its not. Furthermore, you'll then have a nightmare that some non "new" allocated variables or non-selfcleaning "new" allocated variables will not get freed because an unexpected and unhandled exception happened to throw execution of the code to some other caller function. This would definately be a severe problem within the kernel, especially with the current C code base. I actually like the idea of being able to use exceptions, but without the ability to continue processing where execution left off your error handling gets severly limited and you end up having to code something that looks very similar, if not more complicated and verbose, than the original error condition check. And as far as understandability, debugability, and clearness go, exceptions can cause the execution of unexpected code or the lack of execution of code that was expected to be executed and these problems are not as easy to trace down as the original error check. With error checks a simple read through of the relevent function easly bring to light most error checking bugs. An exception bug however, causes you to have to hunt through the relevant function, the functions who call that function, and the caller's of those, and so on. Not a fun way to spend coding time.
> > 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
I can see at least some good uses. Start by using it as a better C, strong type checking, etc. Perhaps use some of its features to get rid of fancy uses of preprocessor macros, which are usually somewhat cryptic. Port various structures to classes. The programming of modules may be especially enhanced, perhaps by having all modules inherit from a generic module. Even better this would allow for easy changes of different parts of the kernel, like interchangable parts. For example, choose from different memory managers when cutomizing your kernel. Perhaps one optimize for low memory systems, another for normal users, and yet another for those who must have 4 Gigs. If each MM is derived from a common virtual parent, this cound even be doable at runtime. Or perhaps you want to be able to choose amoung differing disk caches. This could definately be very useful.
>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/
| |