Messages in this thread | | | From | "Anthony Barbachan" <> | Subject | Re: C++ in kernel (was Re: exception in a device driver) | Date | Fri, 8 Jan 1999 00:57:37 -0500 |
| |
-----Original Message----- From: Horst von Brand <vonbrand@inf.utfsm.cl> To: Anthony Barbachan <barbacha@Hinako.AMBusiness.com> Cc: linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu> Date: Thursday, January 07, 1999 2:06 PM Subject: Re: C++ in kernel (was Re: exception in a device driver)
>"Anthony Barbachan" <barbacha@Hinako.AMBusiness.com> said: > >[...] > >> 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. > >I don't see what can be done in C++ that can't be done in GNU C (this is >definitely not ANSI C!) in this area. >
I haven't used any specific options for "GNU C", or at least I do not think I have, so I cannot say if it can give the same benefits as C++. However, as far as I can tell the compiler doesn't even warn about using ancient C or obselete syntaxs.
>> 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. > >The kernel is one huge, carefully object-oriented design. Ever seen the >structs full of function pointers? That's your objects and virtual >functions, written in C. Plus the kernel does stuff that _can't_ be >(cleanly?) expressed in C++: Call this fallback function if the specific
If the kernel were to use some C++, it doesn't mean that everything would have to be implemented in classes. I have many times written C++ programs which were coded completely C-like as far as my code went, but used objects that took care of much of the lower level grunt work or that kept things, like variables and functions, nicely organized and kept stupid mistakes from happening such as passing the wrong pointer to a function. Everything in the kernel would not have to be in C++ to take advantage of the language, however, those parts that can be best expressed in a class form could benefit.
>function doesn't exist, or fails. Change the function to be called at >runtime. > >That these other things you ask for don't exist as separate entities is >because (a) it is harder to write and maintain 3 different memory managers, >for instance. Heck, even _one_ gives the head hackers headache!, (b) it is
Actually I didn't ask for this, I stated that it would be easier to be able to provide something such as that with classes. For example, if you wanted to create a different MM system all you would have to do is make sure you own MM class had the same interfaces as the current MM system; the low level details could vary is many ways but the system would still work if the same interface member functions remained. Basically classes could help keep kernels part very "cookie-cutterable-like" allowing easier dropins replacements or dropouts for other projects.
>often easier to write _one_ version of something that adjusts to different >circumstances than several rigid ones. (c) It is way more flexible. For >example, "low memory" is somebody's 8Mb machine all the time, or some 128Mb >machine under peak load. You'd want the MM to adjust, not to be wired in at >boot or configuration time, and you want it to do it on its own, not by >sysadmin intervention. And (d), Linus has strongly stated here and >elsewhere that he _won't_ _ever_ accept such bloat into the kernel. Mostly >by (a) to (c). > >The first rule of good design is that it is the one from which nothing can >be taken away, not the one to which nothing could be added. Look at some >of the competition, they traded a few % here for a nice feature there, and >another % there for this nifty addition, and now they are a unholy mess. >
Quite true, but keep in mind that an "unholy mess" can also arise when the code base of a project becomes an uncomprehencable jumble of functions, variables, pointers, etc. I recently had to reconstruct a program who's code base had reached this state and it was definately not fun. Now obviously by using C this doesn't mean that Linux will approach this state but by its very nature C++ helps keep things much better catgorized and organized than C can.
>> >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). > >Name mangling is just an internal detail, and everybody mangles differently >on purpose because the internal interfaces are different. If they did not, >you'd be able to link together stuff from different compilers, and the >resulting executable won't ever get off the ground. > >The thing that killed C++ is that the language still changes daily. The
??? C++ is definately not dead, we may not use it much on Linux but most other systems use it extensively.
>language is _hugely_ complex, hard to get right for compilers and
True, but most of the complexity actually comes from the addon libraries so much of this complexity could be avoided, especially if we stay far away from extensive templates, new-style casts, and exceptions (basically the rediculasly most complex new standard).
>programmers. It also has many hidden surprises performance-wise. >-- >Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl >Departamento de Informatica Fono: +56 32 654431 >Universidad Tecnica Federico Santa Maria +56 32 654239 >Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 >
- 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/
| |