FreeLists / openbeos / [openbeos] Re: C++ in the kernel

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> Could someone explain to me which features of C++ I'm not allowed to 
> use in the kernel, preferably with an explanation of why, if 
> possible? And is it the same everywhere, or are certain parts more 
> restricted than others?

Ingo already has told you most of the bits, I am afraid :-)

> OTOH, if someone feels like doing an exhaustive newsletter article on 
> the topic, I'm happy to wait <cough>. :-)

Yeah... some day :-))

> Here's my impression of the current blacklist (some of these have 
> been explained to me before, but the explanations didn't really stick 
> :-):
> - exceptions: not sure why

Exceptions are realized in the C++ link library which doesn't exist in 
the kernel - of course, you could write your own little implementation 
and they would work. But it's not worth it, I think, as it is easier to 
not check against a specific error value (and be safe) as to not caught 
an exception (and be safe) - and you certainly don't want to end up 
with "catch (...)" everywhere.

> - virtuals: not sure why

Virtuals are possible - just RTTI needs some bits from the C++ link 
library that you would have to implement yourself. Of course, that 
would make the kernel dependent on a specific compiler version which we 
want to avoid for the time being.

> - STL: not sure why

Only because it uses features that need aren't provided in the kernel C
++ runtime library. But it's possible to find your way around it, as 
outlined above.

> And here are a couple I'm specifically curious about:
> - new and delete
> - templates (and no, I don't need to know who thinks templates are 
> God
>   given and who thinks they're the spawn of the devil, just whether I
>   can use them or not, thank you :-)

Those will work fine. "new" and "delete" operators both have to be 
defined yourself, but this is easy (it's almost a simple malloc()/
free() on your part).

Adios...
   Axel.