From what Alan says, adding support for C++ exceptions within the kernel is a
matter of the code overhead needed by the language feature and not a restriction of
kernel coding conventions. Of course, the obvious consideration is the cost/benefit
analysis and I readily agree that it would be unlikely that such additional code
bloat could be justified at this time.
Oliver Xymoron wrote:
> On Wed, 6 Jan 1999, Alan Cox wrote:
>
> > For C++ without exceptions you need to provide the 'new' and 'destroy'
> > operators - probably using kmalloc, and since a performance tuned piece of
> > C++ isnt going to gratutiously create/destroy objects it should all work fine.
>
> That'd be delete. One thing that would be cute, provided you could swallow
> the rest of the pill, is that you could overload this operator for each
> kernel structure, automatically making it use the right allocator/flags.
> Unlike C though, the C++ definition of cute is "make it more magical", not
> "make it faster".
>
> > Been there, done that, didnt like it threw it out. There were several problems
> > that came up. Firstly the resulting code was less efficient - that is partly
> > the compiler but does seem to be at least fractionally the language - its very
> > hard to figure out in C++ when you can avoid passing 'self' around for
> > example.
>
> 'this'. You can tell the compiler not to - use the static keyword on
> member functions. For the kernel, I think we'd probably want to come up
> with a way of forbidding the use of some language features, "class"
> probably first on the list.
As you point out - this is a clear (and extremely common) example of
unfamiliarity with the language being associated (unfairly) with a supposed
limitation/downside. Nearly all such comparisons of C to C++ "overhead" fall into
this category. As for forbidding "class" - certainly not! In the same light, you
don't want to suggest or encourage massive conversions of structs to classes either.
> The problem with C++ is not the compiler, it's the language. It encourages
> you to make things opaque. It wants you to do things quietly behind the
> scenes. It wants you to use constructors, deconstructors, dynamic memory,
> copy constructors, inheritance, overloaded assignment operators, temporary
> objects, virtual functions, etc. All of these things can suck performance
> and fatten code in ways that aren't obvious from staring at the code.
While what you describe is certainly possible (and occurs a great deal in code
written by un-knowing/caring developers) it is by no means a requirement. C++ has
succeeded 100% in its stated goal of not paying for what you don't use. I have used
C++ extensively in embedded system projects which have even more stringent
requirements regarding code size and performance than the linux kernel with very
good results. I have even used templates and exception handling within these
projects on a limited basis when justified (templates more and more often now).
C++ (as opposed to any other OO-languages I know that have also been suggested)
can use extensive inheritance, method and operator overloading, and other very
expressive language-supported features with Zero additional overhead as compared to
its C predecessor. To do this successfully requires that you have a good idea as to
what's going on in the compiler. This knowledge of how the language is implemented
is also a requirement of coding the kernel in C as opposed to assembly language - we
just take this knowledge for granted these days. Five to ten years ago you couldn't
do this and similar arguments against C by the assembly language people were made.
The fact is that C++ *does* offer similar expressive benefits for similar (or
less) costs over C as C had over assembly language that finally won it over. The
biggest single arguable point of this position is the one of "portability". I have
had the happy experience of extending the concept of "portability" to one of
"platform independence" thanx to C++ (and, more recently, Java) but I'm afraid that
this experience is still rare with most developers. No question at all, C can be an
extremely portable language (especially when compared to assembly), and perhaps that
was the "killer feature" that made its acceptance as the replacement for asm
inevitable. The question is whether or not the "killer feature" of C++ over C has
been identified or even exists (thus my previous reference (in prior msg) to the
non-standardization of calling conventions and name mangling in C++ but this is moot
for the purposes of Linux since gcc/++ (egcs) is the only compiler that matters that
much). I have no question in my mind that it does (exist) but that not enough people
have experienced it to be convinced.
> The kernel could be rewritten with C++ and objects to be as fast as it is
> now, and probably quite a bit cleaner. Such a rewrite would probably take
> years to do _right_, and would take more design discipline than I've ever
> seen on a project of that size. Not worth it.
Which continues my train of thought in my last paragraph. I believe that this is
inevitable. Not now and not within the next 24 months but eventually this will
happen in one way or another. I don't know how you simply disregard it as "not worth
it" but understand that's not what I'm suggesting when I mentioned support for C++
as a possible feature of 2.3 (or later). Obviously the mere mention of C++ support
within the kernel brings these thoughts to everyone's minds based on the
overwhelming negative responses to the concept here on the kernel list (although
I've had several pro-C++ private messages! Wonder why that is???).
I think that we can start taking advantage of strong type checking and other
"enhanced-C" features of C++ without paying any performance penalty. This is not an
issue of using the latest tool or programmer's toy because its there. This kernel is
getting feature rich real quick and organizing its growth is getting more and more
difficult (someone ask Linus!). We better start letting the compiler start doing
some of the menial tasks for us so the geniuses (and I use this word literally) who
have gotten us this far can concentrate on keeping this thing from getting the size
of NT-2000 and making adding new features nearly an impossible task.
> One day, computer power will eventually outstrip demand, and OS engineers
> will be free to use friendly languages like LISP again.. until then, I
> think we're stuck with C.
1. This will never happen. I'll always be able to use every cpu cycle and bit
(and square inch of video real-estate!) you can give me.
2. The cost of supporting/implementing new features in large systems will
REQUIRE a language that better enforces their design models.
The linux kernel has got to be an extensible piece of code and that's eventually
going to require a language that's easily extensible itself. Today the cost in code
size and development effort to redo large kernel sections in feature-rich C++ is
certainly is not justifiable as shown by the recent successes in extending the
kernel's support for new features. However, it won't be long till the cost of just
designing the feature becomes as great as its implementation. At this point a
language that enforces these design constructs will become a requirement. I suggest
that C++ is the obvious choice for that language because it doesn't require us to
abandon any previous work and was designed with this very task in mind by its
creator (there, I invoked Stroustrup! Who was waiting for this? :-)). Suggestions of
Objective C, SmallTalk, Java, et al fail to even begin to qualify under these
considerations. I propose that we start supporting the compiler now so when it
becomes time to start this evolution the effort will be much less. The word "object"
and its associated buzzwords don't even have to enter into the discussion.
The alternative is that some other language will pop up (Java?!?!?) that will
offer the expressiveness/performance ratio needed to do all this anew. At that point
linux (as we know it) gets abandoned and we'll all be looked at like the current
generation views those guys who lived in the "hippy" days. I'd prefer to evolve.
regards,
Ben Scherrey
PS: FWIW the true goal of this thread is to deal with my concern with the inevitable
increase in complexity of Linux and how to keep the momentum going. The issue of C++
as a language is obviously the "solution" that I feel most appropriate but I'm not
fixated on it. If the kernel guru's tell me that the answer is "NO!" then so be it.
In this line of work ideas are a dime a dozen and I can't argue with the folks who
have demonstrated their righteousness by what they've delivered. I'm an extremely
happy benefactor of their efforts - I just don't want them to end up on the bit
pile. Meanwhile, I happen to be a happy benefactor of the wonderful C++ language and
think the two have a great potential together.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/