Messages in this thread | | | From | "Anthony Barbachan" <> | Subject | Re: C++ in kernel (was Re: exception in a device driver) | Date | 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/
| |