Messages in this thread | | | Date | Tue, 25 Apr 2006 13:10:09 -0400 | From | "Dmitry Torokhov" <> | Subject | Re: Compiling C++ modules |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |