[openbeos] Re: C++ in the kernel
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 23 Feb 2003 13:34:03 -0500
>> 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:
