I use C and C++ extensively (30+ years writing C, 25 or so writing C++).<p>I much prefer C when writing systems-level code. It's simpler and a lot more predictable. You don't get the illusion that things like memory management are free.<p>I /have/ written drivers in C++. Here you have to be very careful about memory allocation (calling 'new' in an interrupt handler is usually death, though I've also written very specialized allocators that work in IRQ contexts). STL isn't going to cut it, especially if you're writing something real-time that needs very predictable performance.<p>So, my basic prejudice is that while you can use C++ for systems stuff, you still really need to be close to C semantics, so you're basically buying namespaces and "C with classes" at the risk that some yahoo later on is going to #include <map> and utterly hose things . . .
Has anyone really not seen this in the last two years?<p>Anyway, Linus may be a very experienced C programmer, but that doesn't mean his opinion on C++ carries much weight... I'd be more interested on what someone who actually has a lot of experience in using C++ says. Especially with modern C++ and recent tools, libraries etc, which are very different from what was around five or ten years ago.<p>I suppose it is nice for a change for someone bagging out C++ (however inaccurately) to be advocating C instead of a managed or interpreted language though!
I tend to take everything Linus says with a grain of salt. Not because he's wrong, or because he doesn't know what he's talking about, but there's enough of the puckish troll in him that I tend to read his posts more with an eye to their intended effect, than to what he's actually saying.<p>There are plenty of applications for which c++ is a perfectly sensible language choice. Git isn't one of them.
Now this has me a bit confused, why no love for STL ?<p>I wish Linus had added more detail. Is the complaint that the binaries are too big (not quite, if you strip them of the unnecessary symbols) ? or is it that it can be a tedium to go over the reams of error messages that compilers spit out when things go wrong. The second point I am willing to concede, it requires you to read messages inside out, which lisp does train you into doing. Or is the complaint about something else entirely ?<p>Something else that I hear often that bothers me is the claim that STL adds huge runtime overhead. Maybe it was true with the old compilers, but with the current ones, GCC4.5, Intel its not true at least not in a noticeable way. The whole point of STL was the ability to generate optimized code. I have actually verified that the iterator based access patterns on vectors for instance gets optimized away into simple pointer based indexing into memory blocks.<p>I like STL, in fact I will go so far and admit that I will not code in C++ unless I sense that I will benefit from STL and or templates. Though STL gets used often merely as a container library I think you get more out of it when you use its algorithms. I really like it that I do not have to write for loops (and potentially get the indexing wrong).<p>If one squints the right way, it has map, reduce, filter and
map-reduce all built in (transform, accumulate, innerproduct) though I miss a vararg zip function. An un-ignorable side benefit to using the STL primitives is that if a parallelized version comes along the way, you get a fairly painless way to make your code parallel. You do have force some of your snippets to be sequential to account for the fact that there is not enough work to parallelize. This is the direction were GCC's STL library is headed with its parallel_mode. <a href="http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html" rel="nofollow">http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode...</a><p>@cube Appreciate your comment. For writing kernels and VMs I gladly buy your argument, to add to what you said there is the ABI mess.
Linus' rant is grounded in practicality. Portability concerns are huge for git. Read the source code.<p>Git compiles on lots of (arcane and ancient) Unix flavors, and has to deal with the compilers on those platforms. C is still the right choice for git.
Symbian <i>was</i> written in C++.<p>It was basically C with encapsulation. So using C++ as a better C.<p>It worked well. It didn't use STL nor boost and the exceptions weren't as you'd know them. Memory management was much more carefully counted than is normal in C/C++ programs, and reservation meant commit.<p>It was programmed by a pretty clever disciplined bunch. Well, most of us were ;)
This feels like it was written by a guy who wrote a popular OS and has had people kissing his ass for 15 years. Basically the coding version of a diva musician.
I have used C and C++ extensively (10+ years both). I once tried to implement the C++ inheritance model in a C program (basically just fill up the virtual table manually). It was a complete nightmare, wrought with silly mistakes all over the place.<p>Probably Linus is right that C++ does not belong in the kernel but for application level code reinventing all the basic C++ things in C seems like a waste of time. Linked lists, virtual methods, some form of exception handling.. why waste your time? I laughed pretty hard when I understood how the linked list implementation in the Linux kernel works (pointer arithmetic tricks + sizeof). People don't even invent anything different from whats already in C++.<p>The key to using C++ is to find a comfortable subset and stick with it. I haven't used C++ on projects with more than 3 people yet so I don't know the pains of agreeing on exactly which subset to use but I imagine it could be done.
A discussion which was inspired by this rant by Linus Torvalds on Stack Overflow: <a href="http://stackoverflow.com/q/1995471/89391" rel="nofollow">http://stackoverflow.com/q/1995471/89391</a> (Is learning C++ a good idea?)
Linus's objections seem centered on the fact that it makes it easier to generate bloated code. While this may be true, there's nothing a little self-discipline can't control.<p>STL and Boost may not make sense for the kernel, but there's nothing wrong with using C++ classes at their most basic. The kernel would be far more readable if it used classes and <i>simple</i> inheritance rather than re-inventing the wheel with structs full of function pointers.<p>C++ gives you more flexibility with regard to encapsulation as well - it's hard to argue that that doesn't lead to cleaner, safer code.
This saddens me as C++ is growing into such a beautiful language. C++11 is a major step forward, and I don't really buy in to complaints that are not about the current standard.<p>Bad programming is language agnostic. Disliking a language generally implies that you don't know enough about it to really get it.
I find it interesting how 'everyone' seem to hate C++, yet, so many uses it. If C++ is so bad, why does people continue to code with it? Personally I have just started to look at C++ due to Microsofts integration with it on WinRT/Metro for Windows 8.<p>I mean, MongoDB, Node.js, Microsoft's Windows Runtime (which provides access to the systems API for both JavaScript, C#/VB.NET and C++), MySQL, Membase, Haiku, Chromium are all notable examples of software written in C++ that seems to be quite well.
May I recommend that if you're looking for a more considered critique of the C++ programming language you look at the C++ FQA (Frequently Questioned Answers) instead?<p><a href="http://yosefk.com/c++fqa/" rel="nofollow">http://yosefk.com/c++fqa/</a>
Although it is true that certain languages give you the flexibility of writing "utter crap", I can also write pretty crappy unmaintainable code in pure C just as easily. Nevertheless, after 14 years of coding in C++, I love how beautiful my C++ code comes out. All that "OO crap" makes my code easier to understand, debug, maintain and extend. I would take that at the expense of how much more difficult it is to create binary compatible libraries in C++ (something quite easy in C). I can see how for a kernel, that would be more important.
But Mercurial was written in Python and performance is comparable to git. So, his argument is not correct about the performance reason on choice of C over C++. Even interpreted Python which was used in Mercurial was not speed bottleneck. Yes, I know that most of speed critical sections was written in C. But almost all project in Python.<p>Also Darcs was written in Haskell and Bazaar with Python.<p>I hate C++ too (over 10 years of experience). But Linus is full of <i>BS</i> too.<p>Yes, choice of C language in Git is right choice. But source code of Git is horrible and unmaintainable mess.
Why not take the kernel (it's gpl code) and re-write a major part of it in C++? And then fork that and get others to use it? That would either prove that C++ can be used in kernel or disprove it. We could call it C++nux ;)<p>Then, the BSD guys would have even more reason to call Linux garbage and the OS/language/superiority wars would rage on for even more generations. Wouldn't that be so cool.
I wonder what Linus thinks about Objective C as another as an alternative approach to Object Orientation in C.<p>IMO Objective C gets much farther in implementing polymorphism and dynamic binding than C++ can even dream of.<p>Although I hear good things about Boost, I think thats like patching the language instead of fixing the fundamental flaws in its design.
I've read this "news" like dozens of times, and every time I can't help laughing. What he is speaking of is generally true. If I am not writing in C, then I am writing in ASM for speed, or in LISP for less code. C++ just doesn't fit in my tool chain, because it really doesn't excel in any aspect.
I found a response to this <a href="http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html" rel="nofollow">http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html</a>
Linus is probably the %1 of people in the world who actually needs to get the performance gain that C has over C++ - as for the rest of us? Probably doesn't matter.
I don't <i>completely</i> agree, though I do completely agree when it comes to kernel, embedded, or performance-critical stuff.<p>One thing I love about Torvalds and that makes him great is that he has zero respect for fads. CS is unfortunately very, very faddish. Good ideas like OOP and Agile become fads, and then become universal hammers with everything becoming a nail, destroying whatever virtues these ideas once had.
Its quite fascinating seeing heavy weights have a go at each other. Most of the discussion here is right over my head but I find myself quite enjoying it. At least its better that the current boxing heavy weight scene. This is about the only post on hacker news that I have read comments on from start to finish. Brilliant all!
I submitted an interesting response to this rant a while back.<p>It makes some good points, despite the inflammatory technique of characterizing Linus' rant as being caused by a "C-hacker syndrome".<p><a href="http://news.ycombinator.com/item?id=3416863" rel="nofollow">http://news.ycombinator.com/item?id=3416863</a>
I guess what he meant was signal to noise ratio, i mean, Aplayer/Cplayer ratio. Too many Cplayer programmer start learning c++ without any idea how cpu and memory works, if you let them to mess with the kernels it would be a nightmare for Linus.
Why does the guy Linus is replying to think C's portability is BS? Anything besides the fact that any libraries used in your "portable" program must also be portable?
<i>sigh</i> not this flamewar repost again.<p>The fact that he leads with "language X sucks because it attracts type Y programmers" is quite possibly the worst, cheapest, and lowest attack I've ever seen in technology. It's sad that a technical hero like Linus would basically behave like such a tantrum-throwing child. It reflects poorly on the whole tech community.
But no one can deny that c++ is the most fascinating programming language in this world. You can either spend or waste as long time as you want to __LEARN__ this language and never can say I understand ALL.