DragonFly kernel List (threaded) for 2009-01
DragonFly BSD
DragonFly kernel List (threaded) for 2009-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: C++ in the kernel

From: Michael Neumann <mneumann@xxxxxxxx>
Date: Tue, 06 Jan 2009 01:36:59 +0100

Am 05.01.2009 15:02, schrieb B. Estrade:
> On Mon, Jan 05, 2009 at 02:29:19PM +0100, Erik Wikstr??m wrote:
>> On 2009-01-05 12:33, Jeremy Chadwick wrote:
>>> On Sun, Jan 04, 2009 at 05:06:13PM +0100, Michael Neumann wrote:
>>>> This question bugs me since a quite long time so I write it down...
>>>> FreeBSD had a long thread about pros and cons of using C++
>>>> in the kernel here [1].
>>>> I'm undecided whether it would be good to use C++ in the DragonFly kernel.
>>> Regardless of what folks decide, I ask that everyone keep one thing in
>>> mind (which so far in this thread has not been mentioned):
>>> This is an open-source project. What guarantee is there that all
>>> members of the project (at the time, or in the future) are going to
>>> understand all the intricacies and C++ nomenclature?
>>> This story is not meant to reflect on C++ the language. I hope readers
>>> understand the point of the story, and take into considerations the pros
>>> and cons of said choice.
>> That is a very important consideration, however I would like to point
>> out that for kernel development only a very limited subset of the C++
>> language would be used. I would assume that the most desirable features
>> would be 1) real classes with member-functions as opposed to structs and
>> functions that work on them, 2) inheritance, 3) constructors/
>> destructors, and 4) templates, which are quite easy to understand.
> Is the current code bad or something? What exactly is the problem that
> can be "solved" with C++?

No, the current code is great! And C's simplicity is IMO a good thing
(small is beautiful). But I am in the opinion that C++ *can* produce
better code (in terms of stability) due to it's stronger and richer type
system which allows the programmer to avoid type casts (often found in

Take a look at the driver architeture and you'll see OO all over the
place, just that it's written using a non-OO language. It's not actually
bad, but also not that good either.

But it's nearly impossible to use C++ for that, because it would require
to refactor a *lot* of code into classes. Probably too much.

> For argument's sake, how would you feel about someone suggesting you
> introduce Java, or even Perl, into the core of a C based project? This
> might seem ridiculous, but I think this get's proponents of C++ closer
> to thinking like those that balk at the very thought of "polluting"
> the C code base. Introducing languages with such features is not only
> asking for others to learn new syntax, but a completely new paradigm.
> And when this happens, is it even the same project anymore? My answer
> is, no.

It's actually no new paradigm. It's already used everywhere. A lot of
Unix APIs *are* object oriented (e.g. files). Take a look at drivers or
the VFS, they all use "methods" and even inheritance.

And then in general it's a good thing to learn a new paradigm or a new
language every now and then.



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]