>"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/