Linus Torvalds Will Answer Your Questions

Linus Torvalds was (and still is) the primary force behind the development of the Linux kernel, and since you are reading Slashdot, you already knew that. Mr. Torvalds has agreed to answer any questions you may have about the direction of software, his thoughts on politics, winning the Millenial Technology Prize, or anything else. Ask as many questions as you'd like, but please keep them to one per post. We'll send the best to Linus, and post his answers when we get them back. Remember to keep an eye out for the rest of our upcoming special interviews this month.

Re:Your 2007 Comments on C++

[betterunixthanunix]

his knowledge of C++ seems to centre around 25 year old information

Not really. C++11 is as bad as C++98; for every problem C++98 has that C++11 solves, C++11 introduces some other problem. C++ actually has more problems than C, which is where Torvalds is spot on (he is wrong, though, in saying that C is the only sane choice for anything).

The problem with C++ is that the standard allows programmers to do things that cannot make sense at all. What is "undefined" in C is often "a total disaster, waiting to attack you like Jack the Ripper" in C++. Here, for example, is a C function with undefined behavior:

int f(void){}

See, it says it will return an int, but has no return statements; thus the behavior is undefined. Now, here is a C++ version that will crash your program if you are lucky, but which might actually not crash your program:

std::string f(void){}

See, this time, the compiler is going to try to copy and then destroy the object the function returns. The problem is that such an object is not created, and so whatever the compiler generates will be guaranteed to do something you do not want. This might crash immediately when you call the function; it might call a destructor for some unrelated object; it might even call a member function that is not a destructor, for some object of a totally different type, and you will have no idea why your data is being corrupted until you find that one line (this is made worse by the fact that most C++ programmers will start the debugging process by checking for dangling pointers when data is being corrupted for no apparent reason, yet the offending code has no pointers).

Of course, everyone knows that you are supposed to use a compiler that either forbids this (but the standard doesn't) or turn on warnings so that your compiler will flag it (but it might not). This is the problem with learning C++: rather than learning how to use its features, you really need to learn how not to use its features, and also how to use your compiler's optional features (so much for portability). This is loosely connected to learning C, except that in C you can do OK even if you do not know the "oral tradition" about what should never be done.

Note that this is as true in C++11 as it was in C++98, and C++11 even lets you do things that are even worse. Look at this:

std::function f(void)
{
int i = 0;
return [&](){return i++;};
}

This looks like what I wanted to do: create a lexical closure that increments a counter every time it is called. What this actually does is to screw up everything, because as we all know, you were supposed to use a smart pointer and capture by value. Once again, we see that the language allows you to do something that cannot make sense, and does not force you to do "what everyone knows you are supposed to do."

So, yes, Torvalds was right about C++. Now, C is probably the wrong choice for everything that is not the lowest level of kernel code, but at least the list of "bad things you should never do" in C is concise and mostly clear to someone who understands the abstractions presented by the language. In C++, that list is not concise, it is not obvious even to experts (example: never allow exceptions to propagate out of constructors, which is usually news even to people who know about exceptions and destructors).

I would like to hear Torvalds' opinion on higher level languages and the model used by Emacs: a small core written in C that includes a compiler for a high level language, with the rest written in that high level language.

Re:Your 2007 Comments on C++

[UnknownSoldier]

That letter *completely* misses the point Linus was making.

* C _forces_ a programmer to _always_ be thinking about efficiency.

* C++ _allows_ programmers to be _sloppy_ and not even bother to _think_ about efficiency.

When you have idiots calling a virtual function inside an inner loop because they don't know how a virtual function is _implemented_ that is PRECISELY the type of programmer Linus says is a crap programmer because they have never learnt the 0th rule of programming: TINSTAAFL

There Is No Such Things As A Free Lunch

Yes, C can be tedious, but it encourages a certain mindset. The GREAT programmer is always thinking about the high level theory AND the low level implementation. That is a more _balanced_ programmer then one who doesn't understand how to write atoi() and itoa() (aka printf) which is the typical C++ programmer.

The STL is a great example of the "rebuttal" completely ignorant of real-world needs.

The API _design_ of the STL is great because it is orthogonal and consistent. However STL is total crap when you need to :

- debug a container
- serialize and unserialize it in a FAST and PORTABLE manner

Part of the problem is that C++ compilers are crap and put out verbose messages because they can't output a simple, short type alias.
When you have tools like "An STL Error Message Decryptor for C++" you know your language _design_ AND _implementation_ is FUCKED. Sadly the C++ community doesn't have the balls to be honest and admit their ego is out of control. "OK, We screwed up in certain areas of the language. How could we simply the grammar and language for people _using_ the language AND people _implementing_ the language?"
http://www.bdsoft.com/tools/stlfilt.html [bdsoft.com]

_That_ is why Linus says STL is crap. Programmers start using C++ features without thinking about the _consequences_. A hard-core C programmer will go "OK, this looks like a great design -- where are the areas where it excels in, and where are the areas where it sucks in?" In C you are locked into someone else's bad design.

To prove my point: WHY do you think EA (Electronic Arts) invented their OWN version of STL for game programming? Because the standard C++ STL has several KEY DESIGN FLAWS. Ignoring them doesn't make it go away!
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html [open-std.org]

C++11 _finally_ got Move Semantics. Gee, we've only had to deal with _that_ problem for the past 20 years. Typical over-engineer design-by-committee C++ ignoring real-world (performance) problems.

In closing, there are 2 points I'd like to make:

The *best* programmer is one who balances the simplicity of C with the features of C++; on that I agree that Linus is incorrect. Sadly you can't disable all the crap in C++. Linus' only _pragmatic_ solution was to ban the language outright. His project, his call.

and

The author(s) of the rebuttal need to put up or shut up -- when they have shipped their own kernel THEN they will have earned the right to disagree with Linus.

Hope this provides a little more insight into why C and C++ both suck. ;-/