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

Steven Roberts (strobert@ata-sd.com)
Tue, 12 Jan 1999 10:41:42 -0800

Tor Arntsen wrote:
>
> In article <fa.gfmef4v.1qjmpqe@ifi.uio.no>,
> Chip Salzenberg <chip@perlsupport.com> writes:
> >We're doing such a complete rewrite with Perl right now. It's a
> >big project, even though the fine points of Perl aren't nearly as
> >razor-sharp as the fine points of Linux.
>
> You mean you're rewriting Perl in C++? I hope I just misunderstood..
> If, however, that's what you're saying then I'll stay with the last C
> version of Perl, that's for sure.
>
> C++ code not maintained by the original developer seems to end up
> unmaintained almost always.
> (e.g. who's been fixing groff the last years? Nobody. I remember
> struggling with a sick groff problem once, turned out the compiler didn't
> generate correct code for one slightly complicated statement. There are
> far more bugs in C++ compilers, as an example look at the bug reports on
> comp.sys.sgi. The number of bug reports on C++ is one or two orders of
> magnitude higher than for the C compiler. It won't change either, C++
> compilers are harder to get right than C compilers.)
>
> As far as I'm concerned I'm done with C++ forever. Even thinking of the
> fact that I thought C++ was a pretty good idea some years back is
> quite embarrassing now.
>
This all comes down to one basic point:
You can write crappy code in any language.

(well any language that is in real use... there may be some theoretical
language out there that doesn't let you right bad code, but it probably
doesn't let you get anything done either).

You can write very clean maintainable C++ code. I know, I have and I am
doing it.
You can write very ugly, and non maintainable C code. I know I've seen
it.

The key is not what language you use, it is having good discipline and
then using a language that helps you write good code. And used
correctly, C++ can help you.

BUT, I'm not advocating C++ in the kernel. for one thing, in C++ it
works much
better if your memory allocation is simple (you basically have a big
flat block to divvy up). In the kernel we are constantly tweaking how
drivers can get memory and from where
(okay maybe not constantly, but I have seen enough discussion/patches
fly by over the
last few years that I think C made this task easier).

The kernel already has a plan to it, and the low levelness required in a
kernel seems to lend itself better to C (C++ is lower level than a lot
of language, but C is even lower, you know exactly what you are dealing
with when you write code). We also have a big
advantage in that Linus has made a good Benevolent Dictator which has
helped us
keep the common feel (which I am not meaning to snub the other people
who have helped in this area)

And yes, you can make evil sick and disgusting C++ code. But you have
programming styles and guidelines that forbid bad things. But you have
to forbid similar things in C code. And what you forbid depends on the
project. For a higher level user-land application you can generally
afford to lose some effienciency to gain maintainability. And so your
rules might be tighter (for some of the programs I write being able to
have someone else read and maintain the code 3 years from now is far
more important than a 5-10% performance boost now).

It all comes down to the programmer. Saying C++ is bad becuase you can
write bad code is nonsense. Moronic programmers who shouldn't be
allowed near code will always find a way to write crappy code no matter
what the language.

Regards,
Steven Roberts

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