Re: C++ in the kernel

["B. Estrade" <estrabd@xxxxxxxxx>]

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++? 

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.

And if you say that no new paradigm is needed since C syntax is
encapsulated within C++, then what's the point of even switching?
Mixing languages is bad enough, but mixing paradigms is orders of
magnitude worse. So, if you're not going to take full advantage of a
language's features *everywhere*, what is the point?

I should note that a personal friend of mine who works for M$ tells me
that while they use C++, they most certainly do not make judicious use
of it's OOP features. In fact, he told me that most of the code he's
seen and worked on uses C++ as nothing more than a fancy way to manage
C-style structs as classes. So again, what's the point?

> 
> Of course, to be honest I don't see C++ in the kernel any time soon (or
> ever) since I expect that just the work on getting the infrastructure in
> place would be quite high (getting new to work as it should, probably
> some compiler and linker issues, etc.).

I think it goes back to the point of not alienating the vast majority
of your contributor base. Learning the mindset of how a project uses a
particular language should be a minimal curve. Most energies should be
spent on solving the hard problems brought on by the project's goals.

Cheers,
Brett

> 
> -- 
> Erik Wikstr??m