Re: C++ in kernel (was Re: exception in a device driver)

Anthony Barbachan (barbacha@Hinako.AMBusiness.com)
Mon, 11 Jan 1999 00:16:43 -0500


-----Original Message-----
From: Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
To: Anthony Barbachan <barbacha@Hinako.AMBusiness.com>
Cc: Horst von Brand <vonbrand@inf.utfsm.cl>; linux-kernel@vger.rutgers.edu
<linux-kernel@vger.rutgers.edu>
Date: Saturday, January 09, 1999 11:46 PM
Subject: Re: C++ in kernel (was Re: exception in a device driver)

>"Anthony Barbachan" <barbacha@Hinako.AMBusiness.com> said:
>> Horst von Brand <vonbrand@inf.utfsm.cl> said:
>> >"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.
>
>I refered to creative #defines and such. And re obsolete syntax, egcs is
>getting pickier. You can always increase the warning level...
>
>
>[....]
>
>> 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.
>
>Doing this _right_ would mean to redesign/rewrite the whole kernel from the
>ground up. To patch C++ into it just won't cut it, IMO. BTW, C++ and C are

Well I've written many programs that are hybrids of C and C++ code, many
times basically using one or the other as little more than a wrapper for the
other. And everything works perfectly well and is perfectly maintainable,
and that made it the _right_ this to do.

>starting to diverge seriously, if I'm not very mistaken from cursory looks
>at discussions on C9x and the C++ standard, so to get it to compile as GNU

They are not diverging seriously, in fact one of goals of C9x is to maintain
its current relationship to C.

>C or as GNU C++ will get increasingly dificult. And mixed stuff is just an
>accident waiting to happen.
>

These small incompatabilities, which are relatively rare when using C++ as
an enhanced C, are mostly (if not all) one way which means that with a few
fix ups (if any) the current code base should be able to be compiled with
C++ and could even maintain compatability if kept in enhanced C mode.

>[...]
>
>> >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.
>
>The things where this is useful (filesystems and VFS, all sorts of device
>drivers) have been taken care of, and the result works fine so far.
>

This is not the same as a drop in replacement.

>[...]
>
>> >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.
>
>C++ _can_ (in the hands of capable designers and programmers) help in this
>way. So can C, perhaps with somewhat harder work. Both have the possibility
>of creating an unholy mess. Perhaps C++ more than C as things stand today
>(shifting standard, incomplete adherence to whatever standards exist, much
>less experience working around the language's limitations).

First of all the shifting standard was only because compiler makes started
incorporating features of the new standard before they were decided upon.
Second C is about to a standard revision of its own.

>
>[...]
>
>> >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).
>
>All this is what makes C++ useful: Just as C, C++ is mostly libraries. And

C++ is not mostly libraries, thats like saying the same of C. You can
program a C++ program without ever using a standard C++ library/object, just
as you can do with C.

>the "ridiculously most complex new standard" has been created exactly for
>the sake of really enabling OO design in C++, and making the language safer

STL is not really OO and is not required to make a nice C++ OO program,
neither is the current implementation of exceptions.

>(for me, the jury is still out on these...). So if you don't use them, you
>can stay with C and don't feel much difference.

There is a huge difference in the feel of using classes over structures and
their loosely associated functions.

>--
>Horst von Brand vonbrand@sleipnir.valparaiso.cl
>Casilla 9G, Viņa del Mar, Chile +56 32 672616
>

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