Re: C++ in kernel (was Re: exception in a device driver)

tytso@mit.edu
Sat, 9 Jan 1999 11:35:09 -0500


Benjamin's posting had the following contradiction which I think really
points out why I am very suspicious about C++ as a language:

>...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.

... but yet earlier, he stated:

> 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.

This is precisely why I don't like C++. It take an awful lot of work to
reverse engineer what a C++ compiler is doing when there's overloading,
virtual classes, type coercion, function overloading, and all the rest.

On the one hand, C++ advocates keep saying that "the compiler will
make things easy, because then we won't have to think about it". Yet
when folks argue about performance, the argument is "you just have to
know what the compiler is doing". This often means not just being an
expert C++ programmer who can second guess the compiler, but searching
through hundreds of C++ header files to see exactly how the classes
were implemented!

The question then is: how does the time savings spent by the
"automatic" work done by the compiler (which we currently do manually)
compare with the effort of figuring out why the following seemingly
simpler line of C++ code:

a = b + c + d + e(b,c)

which might result in several constructors, destructors, mysterious
type castings, etc. works the way it does? And let's not even talk
about function overloading when combined with type coercion. Trying
to figure out which version of function e will be called can be its
own adventure/mystery story. Thus, often C++ has *increased* the
amount of work and complexity I've had to deal with, NOT decreased it.
(Especially when I've had to maintain other people's C++ code.)

Fundamentally, there are a lot of people out there who can't write
good C++ code, and bad C++ code is infinitely worse than bad C code.
I've always thought it telling that no one has ever bothered to hold
an obfuscated C++ contest. Maybe it's simply too easy to write
obfuscated C++ code?

This is why IMHO handing C++ to the average programmer seems roughly
comparable to handing a loaded .45 to a chimpanzee. Sure, a trained
expert can handle the handgun safely --- just as a trained, expert OO
programmer can write clean C++ code. However, I don't want to be
anywhere in the vincity when a monkey starts playing with the .45,
just as I don't want to be nearby when the average programmer starts
playing with the C++ language. (And there are probably more people
with safety training with small arms than there are competent C++
programmers. :-)

- Ted

P.S. This is the exact same argument why I believe threads have no
place in many application programs. It's not that threads are bad, but
they're complicated, and if you can program threads well, you'd be a
good kernel programmer. (And we've seen how hard it is for kernel
programmers to get this right, given the various race conditions and
dead locks we've found in the kernel over the years.) And we want to
put all of this complexity and potential for lossage in the hands of
*applications* programmers, who generally have far less experience in
this sort of thing that we do?!? Pardon me if I seem unconvinced....

Yes, yes I know --- call me a traditionalist. But I've had real-world
experience having to work with or maintain other peoples' attempts at
threads or C++ code ---- and the old saying that a conservative is a
liberal who's been mugged is very much applicable here.

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