Re: Compiling C++ modules

["Dmitry Torokhov" <dmitry.torokhov@gmail.com>]

On 4/25/06, Avi Kivity <avi@argo.co.il> wrote:
> Kyle Moffett wrote:
> > On Apr 25, 2006, at 03:08:02, Avi Kivity wrote:
> >> Kyle Moffett wrote:
> >>> The "advantages" of the former over the latter:
> >>>
> >>> (1)  Without exceptions (which are fragile in a kernel), the former
> >>> can't return an error instead of initializing the Foo.
> >> Don't discount exceptions so fast. They're exactly what makes the
> >> code clearer and more robust.
> >
> > Except making exceptions work in the kernel is exceptionally
> > nontrivial (sorry about the pun).
> My experience with exceptions in kernel-like code (a distributed
> filesystem) was excellent.
> >
> >> A very large proportion of error handling consists of:
> >> - detect the error
> >> - undo local changes (freeing memory and unlocking spinlocks)
> >> - propagate the error/
> >>
> >> Exceptions make that fully automatic. The kernel uses a mix of gotos
> >> and alternate returns which bloat the code and are incredibly error
> >> prone. See the recent 2.6.16.x for examples.
> >
> > You talk about code bloat here.  Which of the following fits better
> > into a 4k stack?
> The C++ code. See below.
> > Which of the following shows the flow of code better?
> Once you accept the idea that an exception can occur (almost) anywhere,
> the C++ code shows you what the code does in the normal case without
> obfuscating it with error handling. Pretend that after every semicolon
> there is a comment of the form:
>
>    /* possible exceptional return */
>
> once you think like that, you can see what the code actually does rather
> than how it handles errors. A 15-line function can do something
> meaningful, not just call two functions.
> >
> > C version:
> >     int result;
> >     spin_lock(&lock);
> >
> >     result = do_something();
> >     if (result)
> >         goto out;
> >
> >     result = do_something_else();
> >     if (result)
> >         goto out;
> >
> >     out:
> >     spin_unlock(&lock);
> >     return result;
> >
> > C++ version:
> >     int result;
> not needed unless you actually return something.
> >     TakeLock l(&lock);
> >
> >     do_something();
> >     do_something_else();
> >
> > First of all, that extra TakeLock object chews up stack, at least 4 or
> > 8 bytes of it, depending on your word size.
> No, it's optimized out. gcc notices that &lock doesn't change and that
> 'l' never escapes the function.

"l" that propects critical section gets thrown away??? What is the
name of the filesystem you ported? I mean, I need to know so I don't
use it by accident.

--
Dmitry