Newsgroups: fa.linux.kernel
From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: [PATCH] 2.5.6-pre2 IDE cleanup 16
Original-Message-ID: <a65uju$be7$1@penguin.transmeta.com>
Date: Wed, 6 Mar 2002 20:38:26 GMT
Message-ID: <fa.jsv7krv.9igjoe@ifi.uio.no>

In article <Pine.LNX.3.96.1020306105428.386A-100000@gatekeeper.tmr.com>,
Bill Davidsen  <davidsen@tmr.com> wrote:
>
>  Can't disagree, I never understood how people who can understand
>inheritance can be fuddled by pointers to functions.

One thing I'd love to see in C is default values for structure members
in initializers.

Pretty much everything else is trivially done with structures and
function pointers - once you allocate things dynamically you can (and
should) trivially and logically just make the allocator initialize the
needed fields too.  But for static allocations and static initializers
you cannot cleanly do the same thing - you have to add explicit code
that knows about each statically allocated entry.

That's basically the only piece of object constructors that I consider
really _useful_, with the rest just being syntactic fluff.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Compiling C++ kernel module + Makefile
Original-Message-ID: <Pine.LNX.4.58.0401192241080.2311@home.osdl.org>
Date: Tue, 20 Jan 2004 06:48:36 GMT
Message-ID: <fa.j3ccpt9.1d2gkol@ifi.uio.no>

On Tue, 20 Jan 2004, Robin Rosenberg wrote:
>
> This is the "We've always used COBOL^H^H^H^H" argument.

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:

 - the whole C++ exception handling thing is fundamentally broken. It's
   _especially_ broken for kernels.
 - any compiler or language that likes to hide things like memory
   allocations behind your back just isn't a good choice for a kernel.
 - you can write object-oriented code (useful for filesystems etc) in C,
   _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is
either
 (a) looking for problems
 (b) a C++ bigot that can't see what he is writing is really just C anyway
 (c) was given an assignment in CS class to do so.

Feel free to make up (d).

		Linus

Newsgroups: fa.linux.kernel
From: "Theodore Ts'o" <tytso@mit.edu>
Subject: Re: What if?
Original-Message-ID: <20041202044034.GA8602@thunk.org>
Date: Thu, 2 Dec 2004 04:42:38 GMT
Message-ID: <fa.e5s9d8q.j6e1i0@ifi.uio.no>

On Thu, Dec 02, 2004 at 05:34:08AM +0530, Imanpreet Singh Arora wrote:
>
>    I realize most of the unhappiness lies with C++ compilers being
> slow. Also the fact that a lot of Hackers around here are a lot more
> familiar with C, rather than C++. However other than that what are the
> _implementation_  issues that you hackers might need to consider if it
> were to be implemented in C++.

The suckitude of C++ compilers is only part of the issues.

> My question is regarding how will kernel
> deal with C++ doing too much behind the back, Calling constructors,
> templates exceptions and other. What are the possible issues of such an
> approach while writing device drivers?  What sort of modifications do
> you reckon might be needed if such a move were to be made?

The way the kernel will deal with C++ language being a complete
disaster (where something as simple as "a = b + c + d +e" could
involve a dozen or more memory allocations, implicit type conversions,
and overloaded operators) is to not use it.  Think about the words of
wisdom from the movie Wargames: "The only way to win is not to play
the game".

					- Ted

Newsgroups: fa.linux.kernel
From: "Theodore Ts'o" <tytso@mit.edu>
Subject: Re: What if?
Original-Message-ID: <20041202202514.GA5882@thunk.org>
Date: Thu, 2 Dec 2004 20:27:02 GMT
Message-ID: <fa.e5rrd97.j6s3id@ifi.uio.no>

On Thu, Dec 02, 2004 at 03:24:32AM -0500, James Bruce wrote:
>
> I think this oft-repeated argument is a strawman, since C++ and C are
> identical on primitive types, and for non-primitive types, C can't use
> operators anyway.

While that may be true, the problem is that you don't know off the top
of your head whether something like:

	a = b + c + d + e;

involves primitive types or not just by inspection.  So it could be
something that takes no time at all, or a monstrosity which takes a
dozen or more memory allocations, and where it requires a Ph.D. in
understanding obfuscated code to figure out which overloaded operators
and which type coercions had actually taken place.  And remember, this
is a language where you can even override the comma (',') operator.
You think you know what a piece of code will do just by looking at it?
Think again!

This is perhaps one of the reasons why no one has bothered to make a
C++ analogue of the Obfuscated C Programming Contest.  There simply is
no challenge involved.  I have seen proprietary codebases written in
C++, where said codebase was the crown jewel of the company, and while
the original C code was understandable, when it was re-written in C++,
it was completely unmaintainable and impossible to understand what was
going on.  I was reduced to placing printf's all over the place just
to figure out the flow of control.

(Out of respect to the company involved, I won't name names, but it
was a filesystem-related product, and I was adding ext2 support to the
codebase at the time.  While on paper it may have made sense to use
C++ classes to represent different filesystem drivers, the
implementation was a complete and mitigated disaster, IMHO.  And this
is not the only C++ project I have seen where it would have been much
easier to understand the darned thing if it had been written in C
instead.)

On Thu, Dec 02, 2004 at 08:33:44AM +0000, J.A. Magallon wrote:
> Don't ge silly. I have written C++ code to deal with SSE operations
> on vectors, and there you really need to control the assembler produced,
> and with the correct const and & on correct places the code is as
> efficient as C. Or more. You can control everything.....
>
> It is as all things, you need to know it deeply to use it well.
> There are a ton of myths around C++.

If you know how to use a table saw deeply and well, you can use it
safely even with all of the safeties disabled and the blade guard
removed.  There are even a few cases where you have to do this.
However, I wouldn't recommend it for most people since it is far too
likely they will lose a finger or a hand....

That's the problem with C++; it is far too easy to misuse.  And with a
project as big as the Linux Kernel, and with as many contributors as
the Linux Kernel, at the end of the day, it's all about damage
control.  If we depend on peer review to understand whether or not a
patch is busted, it is rather important that something as simple as

	a = b + c;

does what we think it does, and not something else because someone has
overloaded the '+' operator.  Or God help us, as I have mentioned
earlier, the comma operator.

> In short, with C++ you can generate code as efficient as C or asm.
> You just have to know how.

You can juggle running chain saws if you know how, too.  But I think I
would rather leave that to the Flying Karamazov Brothers.

							- Ted

From: Al Viro <viro@ftp.linux.org.uk>
Newsgroups: fa.linux.kernel
Subject: Re: Compiling C++ modules
Date: Tue, 02 May 2006 13:34:49 UTC
Message-ID: <fa.22nu5M3av8NZPY+8PwK9HcFt200@ifi.uio.no>
Original-Message-ID: <20060502133416.GT27946@ftp.linux.org.uk>

On Tue, May 02, 2006 at 01:32:05PM +0300, Avi Kivity wrote:
> Like the recent prevent_tail_call() thing? Granted, C++ is a lot tricker
> than C. Much self-restraint is needed, and even then you can wind up
> where you didn't want to go.

	Sigh...  You know, once upon a time there was a language called
Algol 68.  It had a _lot_ of expressive power and was fairly flexible -
both in type system and in syntax.  And it had been a fscking nightmare
for large projects.  Not because of lack of modularity - that part had
been all right.  The thing that kept killing large projects was different;
in effect, each group ended up with a language subset and developed a
discipline for it.  And as soon as they mixed, _especially_ if they were
close, but not quite the same, you had an ever-growing disaster.

	It's not easy to quantify; each language has dark corners and
there are more or less odd constructs specific to individual programmers
and to groups.  And yes, you certainly can write unreadable crap in any
language.  The question is, how many variants of "needed self-restraint"
are widespread, how well do they mix and how easy it is to recognize the
mismatches?  It's not a function of language per se, so it doesn't make
sense to compare C and C++ as languages in that respect.  However, C++
and C _styles_ can be compared and that's where C++ requires more force
to keep a large project away from becoming a clusterfsck.

	Sure, you need make sure that different groups of people use
more or less compatible styles anyway; it's just that with C++ you need
tighter control to get the same result.  And for kernel it's a killer.

From: Al Viro <viro@ftp.linux.org.uk>
Newsgroups: fa.linux.kernel
Subject: Re: Compiling C++ modules
Date: Tue, 02 May 2006 14:34:54 UTC
Message-ID: <fa.GmLdprtWXGjwAsG0eA+vGwpePD0@ifi.uio.no>
Original-Message-ID: <20060502143430.GW27946@ftp.linux.org.uk>

On Tue, May 02, 2006 at 05:02:55PM +0300, Avi Kivity wrote:
> Hey, I agree 100%, except for the last 6 words :) C++ is the very worst
> language I know in terms of badly thought out features, internal
> inconsistencies, ways to shoot one's feet off, and general ugliness. It
> will require _very_ tight control to avoid parts of the kernel going off
> in mutually incompatible directions.
>
> But I think that the control is there; and if C++ is introduced slowly,
> one feature at a time, it can be kept sane. And I think there is
> definitely a payoff to be won out of a switch.

You are far too optimistic.  In the best case it'll end up with higher
artificial entry barrier for contributors.  In the worst (and much more
realistic) the crap will leak all over the tree in addition to the
already present classes of bugs.

"Everyone has his pet subset/extension" is a killer for anything that isn't
done by 5-6 people, or, at least reviewed by 5-6 people who really can
read through _all_ incoming code.  For something like Linux kernel...
forget it.  It's far outside of the area where that would work.

From: Al Viro <viro@ftp.linux.org.uk>
Newsgroups: fa.linux.kernel
Subject: Re: Compiling C++ modules
Date: Tue, 02 May 2006 15:15:52 UTC
Message-ID: <fa.xs+fqmwLPir3TSox6AzUpx6iuPU@ifi.uio.no>
Original-Message-ID: <20060502151525.GX27946@ftp.linux.org.uk>

On Tue, May 02, 2006 at 06:04:23PM +0300, Avi Kivity wrote:
> BTW, C++ could take over some of sparse's function:

And the point of that would be?  sparse is _fast_ and easy to modify;
g++ is neither.

From: Al Viro <viro@ftp.linux.org.uk>
Newsgroups: fa.linux.kernel
Subject: Re: Compiling C++ modules
Date: Tue, 02 May 2006 15:29:02 UTC
Message-ID: <fa.d+NK6flwDrCgm/UTf2CtMvNZLzk@ifi.uio.no>
Original-Message-ID: <20060502152837.GY27946@ftp.linux.org.uk>

On Tue, May 02, 2006 at 06:19:35PM +0300, Avi Kivity wrote:
> Al Viro wrote:
> >On Tue, May 02, 2006 at 06:04:23PM +0300, Avi Kivity wrote:
> >
> >>BTW, C++ could take over some of sparse's function:
> >>
> >
> >And the point of that would be?  sparse is _fast_ and easy to modify;
> >g++ is neither.
> >
>
> I wasn't talking about modifying gcc to do the checking, rather using
> language features so that the checks would happen during a regular
> compile. That would mean we weren't dependent on somebody running sparse
> with a configuration that triggers the bug, but those few who compile
> the code before submitting the patch would get it automatically checked.

g++ won't cover all checks sparse is capable of, so you still want to
run the latter over new code anyway (== pass C=1 to make).  IOW, type
safety from C++ isn't particulary good argument.

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: C++ pushback
Date: Wed, 26 Apr 2006 20:10:34 UTC
Message-ID: <fa.NB/mev2Us42uSkCoeSeyfvpk+KI@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0604261305010.3701@g5.osdl.org>

On Wed, 26 Apr 2006, Jan-Benedict Glaw wrote:
>
> There's one _practical_ thing you need to keep in mind: you'll either
> need 'C++'-clean kernel headers (to interface low-level kernel
> functions) or a separate set of headers.

I suspect it would be easier to just do

	extern "C" {
	#include <linux/xyz.h>
	...
	}

instead of having anything really C++'aware in the headers.

If by "clean" you meant that the above works, then yeah, there might be
_some_ cases where we use C++ keywords etc in the headers, but they should
be pretty unusual and easy to fix.

The real problem with C++ for kernel modules is:

 - the language just sucks. Sorry, but it does.
 - some of the C features we use may or may not be usable from C++
   (statement expressions?)
 - the compilers are slower, and less reliable. This is _less_ of an issue
   these days than it used to be (at least the reliability part), but it's
   still true.
 - a lot of the C++ features just won't be supported sanely (ie the kernel
   infrastructure just doesn't do exceptions for C++, nor will it run any
   static constructors etc).

Anyway, it should all be doable. Not necessarily even very hard. But I
doubt it's worth it.

		Linus

From: Al Viro <viro@ftp.linux.org.uk>
Newsgroups: fa.linux.kernel
Subject: Re: C++ pushback
Date: Wed, 26 Apr 2006 20:19:31 UTC
Message-ID: <fa.3AKcQS/Ns5iw6/T7OI6Z2kE7SKE@ifi.uio.no>
Original-Message-ID: <20060426201909.GN27946@ftp.linux.org.uk>

On Wed, Apr 26, 2006 at 01:09:38PM -0700, Linus Torvalds wrote:
> The real problem with C++ for kernel modules is:
>
>  - the language just sucks. Sorry, but it does.
>  - some of the C features we use may or may not be usable from C++
>    (statement expressions?)
>  - the compilers are slower, and less reliable. This is _less_ of an issue
>    these days than it used to be (at least the reliability part), but it's
>    still true.
>  - a lot of the C++ features just won't be supported sanely (ie the kernel
>    infrastructure just doesn't do exceptions for C++, nor will it run any
>    static constructors etc).

   - a lot of C++ advocates agree that some subset could be used sanely,
     but there's no agreement as to _which_ subset would that be.