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.
Linus Torvalds on C++
11–20 of 190 posts
Re: Linus Torvalds on C++
#12Linus 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.
> needs to get the performance gain that C has over C++
With RTTI and Exceptions disabled you should be able to get almost identical performance with C and C++. In some cases C++ compiler has additional information that can allow it to produce faster code as well.
Re: Linus Torvalds on C++
#13Has anyone really not seen this in the last two years? 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. I suppose it is nice fo…
I think we're missing the point here. Taking the side of the customer of git, I'm happy. I type things on a CLI with git and things happen pretty fast. I'm happy. I don't care whether you wrote it with C, C++ or Haskell. It works. It works just fine. To Linus's point, I've never used, or even heard of someone using Monotone. That must say _something_.
I've used Monotone. It's pretty horrible if you ask me.
Re: Linus Torvalds on C++
#14I 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. There are plenty of applications for which c++ is a perfectly sensible language choice. Git isn't one of them.
If I understand what proponents of C++ say, C++ is supposed to be suited best for medium-level programming where abstraction is helpful but low-level constructs and speed are still helpful. It's supposed to give you many of the benefits of higher level languages while still giving you high performance. It's intended to be widely portable but still easily hook into special OS-specific facilities.
This description sounds like an excellent language for git to me. And in fact, while I don't like C++ much in general, if properly managed, I think a project like git could do well if written in C++.
Re: Linus Torvalds on C++
#15A discussion which was inspired by this rant by Linus Torvalds on Stack Overflow: http://stackoverflow.com/q/1995471/89391 (Is learning C++ a good idea?)
I don't know C++. The accepted response does not start off well. "C++ is a complex language, and if you don't learn it properly, it's very easy to shoot yourself in the foot. And that is also why you shouldn't listen to most non-C++ programmers hate towards C++. Most of the time, they didn't learn the language properly, so they're not really able to judge the language" What does that mean? It sounds like, that withou…
Most people learn C++ as a feature-by-feature increment over C. This means they generally write function-oriented programming with objects instead of object-oriented programming, mix exceptions with returning errors, stick with pointers and char*'s instead of references and string's, and end up rewriting data structures before finding out about STL.
That being said I use some features of C++ I like (inheritance and STL) and while the result is somewhat bastard C/C++ it does what I need well, which at the end of the day is all we should really ask for from a language.
Re: Linus Torvalds on C++
#16Has anyone really not seen this in the last two years? 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. I suppose it is nice fo…
"I'd be more interested on what someone who actually has a lot of experience in using C++ says." I have considerable experience with C++, going back to when it was called C with Classes and you used a preprocessor to convert C with Classes code to C and then compiled the C. What Linus says is pretty much true. I don't expect it to matter though since when people say "I'd be more interested on what someone who actuall…
"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."
So what's his excuse? RE: Linux
Re: Linus Torvalds on C++
#17Linus'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.
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 simple inheritance rather than re-inventing the wheel with structs full of function pointers.
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.
Re: Linus Torvalds on C++
#18This 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.
[deleted]
Re: Linus Torvalds on C++
#19Linus 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.
> needs to get the performance gain that C has over C++ With RTTI and Exceptions disabled you should be able to get almost identical performance with C and C++. In some cases C++ compiler has additional information that can allow it to produce faster code as well.
You also need to not use:
STL(most implementations are too slow)
Boost or STLPort(namespace and compatability issues if you're not producing executables)
Most OO features like inheritance and polymorphism(a lot of that is resolved at runtime, which eats cycles)
Function overloading(debatable, since the compiler should resolve the function signatures at compile time)
You're pretty much left with C with namespaces at that point.
Re: Linus Torvalds on C++
#20Now this has me a bit confused, why no love for STL ?
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 ?
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.
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).
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. http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode...
@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.