[openbeos] Re: C++ in the kernel
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 23 Feb 2003 23:33:00 +0100 CET
"Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx> wrote:
> >> 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.
I have to agree, a `finally' is badly missing in C++.
Exceptions are really handy in some situations, e.g. in parsers. But
agreed, they are probably too dangerous to be used in the kernel.
[...]
> >> - 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.
Maybe, but with a little care that can be avoided. In fact, regarding
containers -- probably the most important part of the library -- there
exists virtually every possible optimized variation (list, stack,
queue, priority queue, map...), which makes it very simple to implement
fast algorithms. And actually, the STL performance is outstanding in
some respects (e.g. sort()).
> >> 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. :-)
Seeing your hand-instantiated code for pools in VM2, I could have
guessed, that they aren't your best friends. ;-)
CU, Ingo
Other related posts:
