[openbeos] Re: C++ in the kernel

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

Exceptions (in C++) are not a really good paradigm for kernel work anyway, 
unless you have a completely C++ kernel. Why, you may ask? Well, let me share 
an experience from VM2. 
I am using exceptions in VM2, WHILE IT IS IN USER LAND, to emulate signal 
handling. 
I recently ran into a situation where the whole VM hung with no explanation. It 
turned out that I had a semaphore locked and threw an exception. When another 
thread tried to run, it was completely blocked.

The solution is one of:
1) A "finally" clause, like in Java, where no matter what code path occurs, 
exception or not, certain things happen.
2) A constructed class (like a BAutoLocker) that will go out of scope when the 
exception occurs
3) Don't use exceptions
4) Replicate all of the "normal exit" code before throwing.

1 isn't an option. 2 could be done. 3 was my final choice and 4 was my interim 
solution.

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

Yes. Also the performance issues. 

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

STL has potential to be a performance issue. This is not a criticism of it, as 
such,
but STL makes it very easy to do bad (slow) things. It also makes doing good 
things
easier. 

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

Templates. Hmph. :-)

Other related posts: