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

Anthony Barbachan (barbacha@Hinako.AMBusiness.com)
Sat, 16 Jan 1999 20:53:08 -0500


-----Original Message-----
From: Theodore Y. Ts'o <tytso@MIT.EDU>
To: Chip Salzenberg <chip@perlsupport.com>
Cc: Tor Arntsen <tor@spacetec.no>; linux-kernel@vger.rutgers.edu
<linux-kernel@vger.rutgers.edu>
Date: Saturday, January 16, 1999 2:52 AM
Subject: Re: C++ in kernel (was Re: exception in a device driver)

> Date: Sat, 16 Jan 1999 00:05:57 -0500
> From: Chip Salzenberg <chip@perlsupport.com>
>
> > C++ code not maintained by the original developer seems to end up
> > unmaintained almost always.
>
> "90% of _everything_ is crap." -- Sturgeon's Law
>
>"...but 95% of everything written in C++ is crap."
> --- Ted's specialization of Sturgeon's Law
>
> Considering the age of groff, I suspect that its design is based only
> on the language of cfront 2.0, or maybe even cfront 1.2. Compared to
> ANSI C++, those are stone knives and bearskins.
>
>C: A circular saw.
>
>C++: Think of it as a circular saw with the safety removed --- it's more
>powerful that way. :-)
>
> "ANSI C++: It's not your father's C++."
>
>Yes, ANSI C++ has even more rope with which you can hang yourself.
>For example, the ability to overload the comma operator. Now there's a
>dangerous language feature for people to misuse....
>

I haven't been crazy with most of the changes in the new standard of C++
either, actually I oppose many of them, but just because they are there
doesn't mean I'll be forced to use them either.

>It's ironic, really. One of the claimed features of C++ is that it has
>ways of enforcing abstractions by not allowing programmers to access
>private class variables. The basic concept is that you don't trust
>programmers enough to honor abstraction boundaries, so you have to
>forcibly restrict them from touching them. (As opposed to simply
>putting a comment in the header file saying, "keep your ugly paws off").
>

The abstraction is to prevent you from making a mistake or from accessing
something that cannot be allowed to be randomly changed for any reason.
Furthermore it allows one to prevent oneself from making a stupid mistake.
Besides, you would have the source so if you want to allow access that isn't
a problem.

>Yet C++ is filled with plenty of language features which are absolutely
>lethal in the hands of an unskilled programmer --- the same programmer
>which earlier we had assumed we couldn't trust not to touch a structure
>member he shouldn't, so we had to make it private or protected.
>

Well C also allows you to do letal things.

>So if the programmer is not trusted to honor abstraction boundaries,
>explain to me again why we trust him not to misuse one of the large
>number of some inherently dangerous language features with which C++ is
>littered?
>

The abstraction bounderies are there to help you prevent bugs from popping
up not because C++ mistrusts you as a programmer.

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

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