8年后战争又起：Linus Torvalds was (sorta) wrong about C++

原文地址为： 8年后战争又起：Linus Torvalds was (sorta) wrong about C++

语言之争永远是热门的话题，无论你是脱离了语言限制的老手，还是初入IT的新人。2007年的时候，Linus曾在一封邮件中大骂C++。原文链接

From: Linus Torvalds <torvalds <at> linux-foundation.org>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (7 years, 26 weeks, 6 days and 28 minutes ago)

On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
> 
> When I first looked at Git source code two things struck me as odd:
> 1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
> it's BS.

*YOU* are full of bullshit.

C++ is a horrible language. It's made more horrible by the fact that a lot 
of substandard programmers use it, to the point where it's much much 
easier to generate total and utter crap with it. Quite frankly, even if 
the choice of C were to do *nothing* but keep the C++ programmers out, 
that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles 
Bader jokingly said "to piss you off", but it's actually true. I've come 
to the conclusion that any programmer that would prefer the project to be 
in C++ over C is likely a programmer that I really *would* prefer to piss 
off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using 
the "nice" library features of the language like STL and Boost and other 
total and utter crap, that may "help" you program, but causes:

 - infinite amounts of pain when they don't work (and anybody who tells me 
that STL and especially Boost are stable and portable is just so full 
of BS that it's not even funny)

 - inefficient abstracted programming models where two years down the road 
 you notice that some abstraction wasn't very efficient, but now all 
 your code depends on all the nice object models around it, and you 
 cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and 
portable C++ ends up to limit yourself to all the things that are 
basically available in C. And limiting your project to C means that people 
don't screw that up, and also means that you get a lot of programmers that 
do actually understand low-level issues and don't screw things up with any 
idiotic "object model" crap.

So I'm sorry, but for something like git, where efficiency was a primary 
objective, the "advantages" of C++ is just a huge mistake. The fact that 
we also piss off people who cannot see that is just a big additional 
advantage.

If you want a VCS that is written in C++, go play with Monotone. Really. 
They use a "real database". They use "nice object-oriented libraries". 
They use "nice C++ abstractions". And quite frankly, as a result of all 
these design decisions that sound so appealing to some CS people, the end 
result is a horrible and unmaintainable mess.

But I'm sure you'd like it more than git.

 Linus

2015年3月10日，时隔近8年，Jefff Cogswell 对此提出抗议。原文链接

With all the new (and new-ish) languages out there, you might wonder why it’s still worth learning C++, a language first invented in 1983. Wedged amidst lower-level languages such as C, C++ went through a spike in popularity in the mid-‘90s, when developers realized it was easily translatable to assembly language; but today’s higher-level languages abstract the processor even further away.

C++ has a lot in common with its parent, C; but C++ does a good bit more behind the scenes. Let’s talk about some of the anger towards C++ over that “behind the scenes” thing; you don’t have to look far to find someone who dislikes C++ specifically because of it.

Check out the latest C++ jobs.

Back in the early 1990s, I worked for a software company as a programmer. The company had recently moved from C to C++, and one of the senior developers was frustrated, complaining that calling member functions required a lookup table behind the scenes (he was referring to the virtual method table) rather than just a straight memory address; that really irked him because he felt it slowed the program down. (Even back then, the impact of the virtual method table was negligible in the applications we were building.)

But perhaps the most famous rant against C++ came from none other than Linus Torvalds. It features some choice bits:

C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

Torvalds had a problem with the library features of C++ such as STL and Boost, which he thinks are a.) unstable, and b.) inefficient, forcing developers to rewrite apps once they realize their code depends too much on the nice object models around it:

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don’t screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don’t screw things up with any idiotic “object model” crap.

Tell us how you really feel, Linus.

There are plenty of rebuttals to his attack, but I’ll just make two points. First, he obviously knows his stuff. Second, C does have its place… if you’re writing systems-level code that you want as tight and portable as possible. That latter concern aside, though, this is the 21st century: Why write dozens of lines of code when a single line of code (as with C++) will do it?

A multitude of companies believe the benefits of C++ outweigh the drawbacks; although higher-level languages such as Python and C# have really taken off, there are still lots of C++ jobs; it’s not going away anytime soon.

Supporters argue that C++ provides a fine mix of C’s low-level aspects (looking at the compiled assembly code, etc.) while providing higher-level attributes found in today’s modern languages. Early in its development, C++ featured a standard template library (STL) with template classes such as vectors and maps, which allows for a certain level of generic programming. The STL allowed programmers to focus on applications-level tasks without having to write their own linked lists and other data structures every time.

But such functionality must be used responsibly. I’ve witnessed a lot of “over-engineering” in my life, wherein people would write reusable classes with several layers of inheritance, even though the reusable class wasn’t actually used more than once; worse, that sort of behavior can result in massive libraries of classes nearly impossible to debug. But I would argue that’s the exception, not the norm; when done right, generic programming and other high-level aspects of C++ can provide enormous benefits.

Along Came C++11
Fifteen or so years ago, as languages such as JavaScript and Python became more popular, programmers began to embrace techniques and styles that, while not new, were easily available in those languages. Meanwhile, a group of C++ experts began putting together a library called Boost, which pushed the features of C++ to the limits, giving programmers access to the techniques commonly used in other, newer languages. Many of the creators of Boost were on the C++ Standards Committee, and some of the Boost features have found their way into the latest official incarnation of C++, called C++11.

Keeping with our theme here, C++11 does even more “behind the scenes” than its predecessors. But that’s not a bad thing, depending on how you use it; for example, C++11 now offers lambda functions as an official part of the language. Lambda functions in C++ have a strange-yet-expressive syntax that might take some getting used to, as you can see in this example (which barely scratches the surface of C++ lambdas):

auto myfunc = []() { cout << “Greetings from the lambda” << endl; };

This creates a function and stores it in a variable called myfunc. (The concept of storing a function in a variable is familiar to programmers in other languages such as JavaScript.) You can use lambda functions in places where you previously might have used function pointers. Yes, they do a lot behind the scenes, but they also hold great potential.

Systems-level programming probably still needs C, but for high-level applications, C++ is a great choice. And judging by the number of C++ jobs today, the language is not going away anytime soon. Now is still a great time to learn this older programming language; don’t let the famous naysayers and their profane soliloquies about inelegance dissuade you.

同样地，后面跟了很多帖子，正反双方激烈论战。

兼听则明，偏信则暗。多听听不同的声音总是有好处的，就算是当谈资看看也不错。

转载请注明本文地址： 8年后战争又起：Linus Torvalds was (sorta) wrong about C++