21–30 of 190 posts
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'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 struct…
I think you got that backwards. Structs full of function pointers predate c++. Going for the ad absurdum, why bother inventing C++, it's just a re-inventing of the structs full of function pointers wheel?
Earlier quoted context omitted.
> 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 t…
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.
Has 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…
I got about 3 pages into the meat of the FQA. I can't bring myself to spend the time to go further, because his counterpoints already seem overwhelmingly specious to me. This leads me to wonder on what grounds you characterize him as "the number one expert on C++" "who knows more about C++ than Stroustrup".
The best reference on C++ that I have seen remains the C++ FAQ. (http://www.parashift.com/c++-faq-lite/) I have also always enjoyed Stroustrup's guidance on his language, and I'm inclined to continue believing he knows at least as much about his own language as anybody, until I see some more convincing evidence to the contrary.
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.
How many distributed version control systems have you worked on and released to the public? Any worth critiquing?
If you're going to ask me if I had worked on any OS kernels or distributed version control systems, the answer is no. But I would also never degrade people who might otherwise be willing to help contribute to my projects based on some idiotic notion of programming language superiority.
At this point I don't even expect anything better out of him because he did something great for the world. I expect better just because at this age he should be an adult.
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.
> 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.
Now 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 tr…
One is due to it's completely generalized nature. Since it's not heavily optimized for either speed or memory use, it tends to perform rather poorly in both areas. Not that acceptable when you're making kernel code, where it's often better to write optimized data structures for the problem at hand rather than just relying on templated code. In that situation, where performance is king, you want to tailor your data structures to fix your problems, rather than the other way around.
STLPort and Boost fare better in this respect, but STLPort in particular leads to the second problem.
The second problem is due to the std namespace. Using the std namespace means things that link in your code, even dynamically, cannot necessarily use other STL implementations. So if the kernel uses STLPort, that means that every other program written on top of the kernel needs to use it.
Now 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 tr…
There are a few problems with STL when writing kernel or API code. One is due to it's completely generalized nature. Since it's not heavily optimized for either speed or memory use, it tends to perform rather poorly in both areas. Not that acceptable when you're making kernel code, where it's often better to write optimized data structures for the problem at hand rather than just relying on templated code. In that si…
The Linux module API/ABI has worse problems than that already.
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. 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 soun…
What it's intended to do is rather different than what it's actually used for in real life..... code talks, anything else is just smoke, right?
IF someone can come alnog and show us a better way in any language, then tehre's something to argue about, otehrwise, the guy who has working code wins over the guy without it, always.