Messages in this thread | | | Date | Sat, 9 Jan 1999 11:35:09 -0500 | Subject | Re: C++ in kernel (was Re: exception in a device driver) | From | tytso@mit ... |
| |
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/
| |