Re: C++ in the kernel

[Erik Wikström <Erik-wikstrom@xxxxxxxxx>]

On 2009-01-05 15:02, B. Estrade wrote:
> 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++? 

Actually I think the current code is quote good, at least the part's of
it that have been changed the last decade or so. And there is no problem
that can't be solved in C (or Fortran or Ada) that can't be solved in
C++. But fact is that many parts of the kernel uses object oriented
programming, but C does not have support for this at the language level
and C++ does. It is also a fact that current code uses macros to create
generic types (such as lists and queues) and once again this is
something that C++ has language level support for.

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

There are of course differences, C++ is intentionally designed from the
ground up to be C compatible, both at the syntactic and semantic level,
and the C++ standard committee is working together with the C standard
committee on a number of issues. Also, most other languages are not
designed to compile to native code, they are either interpreted or run
in a VM, which makes them more incompatible with C and usually adds some
additional overhead (at least when interacting with native code).

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

The thing is that since most valid C is also valid (and semantically
equal) C++ there is no need for a paradigm shift. C++ does however add
support for two additional paradigms: OO, and generic programming, both
already know to some extent by the current developers.

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

This has nothing to do with syntax, and little to do with paradigms (as
explained above). In fact if you think you need to (or even should) use
all the available paradigms everywhere you will end up with a very bad
design. C++ simply offers better support for some of the paradigms
already in use.

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

Code quality and maintainability. Decades of research agree that the
encapsulation and abstraction provided by classes as opposed to strucs
and functions gives higher quality and more maintainability.

-- 
Erik Wikström