lkml.org 
[lkml]   [1999]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: C++ in kernel (was Re: exception in a device driver)
In article <199901091635.LAA00723@rsts-11.mit.edu> you write:

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

Same argument goes for C, though to a lesser extent. When the compiler breaks
down, it's a bit hard to figure what to change in your code to get around
the bug. For instance, I am switching some code from gcc 2.8.1 to
egcs 1.1.1, and I have an awful time figuring out why the resulting executable
is 2% larger (which is problematic as it's supposed to be a boot floppy...)
There are some weird differences in code that are triggered by register
allocation which are difficult to trace to one specific point. Even knowing
whether the newer compiler is better is hard.

I also had to trace bugs through preprocessed inputs. The linux kernel
(and other OS code, for that matter) is an intricate piece of clockwork that
uses intricate macros and inline assembly to do complicated things fast,
but with no type-checking, and in a way difficult to follow for a debugger.

I'll suggest that C++ is much better for this kind of task, as it can do
the same things cleanly, and warn you about problems. You definitely know
C much better than C++, so even with the kind of stunts the kernel-code
must go through, you still prefer C, where C++ would be cleaner (and
generate the same code).

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

There is the same problem with C. The difference is that it's already
been taken care of, and that the experts exist today.

>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.)
You've been working with bad programmers.

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

I concur with that ! A switch to C++ is not going to happen because
of cultural reasons. C++ is a large enough language that it is difficult
to learn to write efficient programs with it. With some skill, it can
outperform nearly anything (template expansions can be incredibly
powerful. Some people are using it to beat Fortran 90 at its favorite
games), but there are nowhere near enough skilled C++ programmers that want
to re-write the linux kernel.

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

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