Re: C++ in the kernel

[Michael Neumann <mneumann@xxxxxxxx>]

Am 06.01.2009 00:48, schrieb Simon 'corecode' Schubert:
> Erik Wikström wrote:
>> 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.
>
> I'd like to see a non-ugly template implementation that can be used like
> our current queue.h/tree.h macros. I don't like C++, but I'd be
> positively surprised it this could be solved elegantly.

Hm, it's very hard to accomplish exactly the same as our queue.h macros.
It's easy to implement a regular list (or in general any regular data
structure). But it's harder when it's embedded in the struct itself.

The Linux-way is probably easier (chaining over struct list_head, and
not over the surrounding struct), nevertheless I tried to implement
kind-of a SLIST equivalent:

  template <class E, E* E::*field>
  struct _SLIST {
    //E() { *field = NULL; }
    E* next() { return *field; }
    ...
  };

  #define SLIST(E, field) \
    E *_##field; \
    _SLIST<E, &E::_##field> field

  struct Process {
    SLIST(Process, list);
  };

  Process *a;
  Process *b = a->list.next();

Note that I only used the macro to avoid writing:

  struct Process {
    Process *_list;
    SLIST<Process, &Process::_list> list;
  };

But it's definitively not nice and I really haven't tested it.. all it
does is, it compiles :)

Regards,

  Michael