lkml.org 
[lkml]   [2004]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Compiling C++ kernel module + Makefile
Linus Torvalds wrote:
> The fact is, C++ compilers are not trustworthy. They were even worse in
> 1992, but some fundamental facts haven't changed:
>
> - the whole C++ exception handling thing is fundamentally broken. It's
> _especially_ broken for kernels.

I second that. The basic reason the C++ exception handling mechanism is
broken is because of what happens when an exception is thrown from a
destructor, during a stack unwind caused by an exception. There are
paths of exception/destructor combinations that you just cannot get out
of correctly. This is perfectly OK for most userland apps, but for
kernels it's definitely not OK.

> - any compiler or language that likes to hide things like memory
> allocations behind your back just isn't a good choice for a kernel.

True, when you're doing code that requires locking etc. you don't want a
destructor coming in and deallocating something that you haven't locked.
I don't see when C++ can hide memory *allocations* though, any more than
C can hide them behind trees of function calls.

> - you can write object-oriented code (useful for filesystems etc) in C,
> _without_ the crap that is C++.

True, C++ _is_ full of crap -- that's what C++ lovers refer to as
"power". For work, I program in C++, and I love it because of the power
of expression. I hate it because of the amount of rope it gives me to
hang myself with. And because most C++ compilers are _so_ immature.
Still, OO can be written in C (cfront does it :) ) but it's not always
convenient. Especially when you're doing inheritance-like things, your C
code will be sprinkled with casts (neatly hidden in macros, probably),
and no C compiler will typecheck that. More static checking is good, I'd
say, so there might be reasons to do C++ if you might otherwise get
bogged down in a sea of casts.

> In general, I'd say that anybody who designs his kernel modules for C++ is
> either
> (a) looking for problems

Mostly true, I guess. But sometimes, if you stick to a wisely chosen
subset, it can work out OK. For instance, exceptions should not be used.
Destructors become much less of a problem when you rule out exceptions,
and especially when combined it with lock objects for the locks. And it
is very well possible to write C++ that is low on allocations, like
kernel code should be. I think writing kernel code in C is also looking
for problems, unless you know exactly what you're doing -- in that
respect, it's pretty much the same.

> (b) a C++ bigot that can't see what he is writing is really just C anyway

This argument can, of course, be made for any language. In that case,
the kernel developers' community can be said to be made up from C bigots
that can't see that what they are writing is really just asm anyway. :)

Anyway, I can definitely see your point if you think of people who use
C++ as an "improved C", without much use of OO and templates etc. There
are lots of people out there who do that, and transferring that mode of
usage to the kernel is simply not a good idea. C++ should only be the
language of choice when you need the things where it shines: inheritance
hierarchies, templates, object finalization.


My opinion is that if people want to use C++ in a module, they must do so:
1. Only if they _really_ need all that crap.
2. Only if they _really_ know what they're doing.
3. Only if they use a proper subset that cooperates correctly with the
kernel.
4. Only if it's worth the extra effort that's needed to use C++ in a
kernel module.

Basically, I think that if you know the problems, and know them well,
you don't need to go looking for them anymore, you might be able to just
walk around them. Let's get back to the situation that started this
discussion: the Click people have shown that they can walk around the
problems (point 2), their code is true C++ (they seem to need all that
crap, point 1) and it works fine inside it's own kernel module (point
3). Who are we to judge them, if it works for them? They don't really
bother us with it -- we only bother ourselves with it *a lot* as soon as
their existence is brought to our attention. :) And I think the only
ones who can tell if it was worth the extra effort (point 4) are they
themselves.

-- Bart
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:00    [W:0.379 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site