Slashdot Mirror
Was Linus Torvalds Right About C++ Being So Wrong?
Nerval's Lobster writes: Perhaps the most famous rant against C++ came from none other than Linus Torvalds in 2007. "C++ is a horrible language," he wrote, for starters. "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." He's not alone: A lot of developers dislike how much C++ can do "behind the scenes" with STL and Boost, leading to potential instability and inefficiency. And yet there's still demand for C++ out there. Over at Dice, Jeff Cogswell argues that C++ doesn't deserve the hatred. "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," he wrote. "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." Was Linus going overboard?
Maybe that's what it is. I write a lot of C code, some of it pretty good, but I just can't "get" C++. I appreciate the class stuff. Heck, I pretty much do the same thing using structs in C but past that, the rest of C++ just loses me.
You can find some really elegant C++ code out there. I am quite fond of the Qt libraries, for example. But Qt is its own C++ dialect. The company I work for codes a lot of our software in C++, and it is really nice, clean, maintainable code. But we have a style guide that everybody has to follow, and that's how we pull it off. Essentially, we are not writing in C++. We're just using a C++ compiler to compile NomLang.
Bad programmers can produce bad code in any language, including one as well/thoroughly specified as Ada. The difference, though, is that what that code actually does is less subject to interpretation by the compiler.
I've observed that two Ada programmers will argue, "Is this program legal?" If the program is legal, they both -know- what the compiler will do (modulo the rare compiler/optimizer bug, which was usually caught through the stringent compiler validation.)
Two C++ programmers will argue, 'What will my compiler do with this code?"
You can find some really elegant C++ code out there. I am quite fond of the Qt libraries, for example. But Qt is its own C++ dialect.
Ditto on Qt. Qt can be a beautiful thing sometimes... but then comes pre-compile, which turns it into an anus-puckering nightmare for those who don't know you're using it ;) .
The company I work for codes a lot of our software in C++, and it is really nice, clean, maintainable code. But we have a style guide that everybody has to follow, and that's how we pull it off.
That should be the norm in any competent shop, though.
Mind you, I've seen shops where styles are horribly mixed-up. That usually happens when Company A buys Company B's codebase and nobody cleans up the stuff from Company B. OTOH, I've seen instances where different teams in the same company decide to become special snowflakes and go their own way, making life into a giant shit sandwich for DevOps, QA, or SCM to eat - especially when they have to point to something and say "...fix that, because it's breaking Jenkins/Tito/unit tests/etc... and WTF man, we have artifacts for a reason!"
But then, I just came out of a Java shop where they were using Geronimo, Jetty8, Jetty9... Java 1.6 and 1.7... all in the same 'effing overall product (just that the components sit on different servers.)
Long story short, it takes discipline to keep everyone rowing in the same general direction - enforced styleguides are a part of that. Discipline also keeps things from becoming an unmanageable mess, if the head coder has the spine for it.
Honestly, I find a random program written in C to be on average FAR less maintainable than one written in C++, usually because they end up reinventing the wheel about 50 times, usually poorly. The C program that I work on at work is one gigantic mass of poor wheel reinvention over and over again. Its impersonation of objects and inheritance (for sending message) is terrible, utterly terrible, it's almost impossible to build and send a message without messing up in some way due to all of the interconnected pointers. The macros they use to try to "simplify" it only make it worse. Some parts of the code have macros nested literally dozens of levels deep.
"Are you hungry? I haven't eaten since later this afternoon." -- Primer
STL and lambda are my main reasons for using C++. They're bloody awesome.
Here's my standard challenge for C people - I've given it many times in these sort of threads and not once gotten a real response that meets the specs. Show me the code (emphasis: show me actual code, don't just say "... this is how I'd do it" and a rough description), full code (emphasis: full) for a program launching a detached (emphasis: detached) thread, such that it can happen an arbitrary number of times with no guarantee that other threads will be done (emphasis, there can be more than one thread at a time), to run the function do_something(Foo a, Bar b) (emphasis: two arguments, arbitrary size) - where the values passed for a and b are variables local to the context that launches the thread (emphasis: local), so they need to be passed by copy, not reference.
This is not at all some sort of esoteric task - launching threads with nontrivial local arguments is pretty basic, there's millions of use cases for something like this. Here it is in C++11:
std::thread([=](){ do_something(a,b); )).detach();
Little short line of code. Surely for such an obvious, non-esoteric task, C can't be much harder, right? Any takers?
(Don't bother responding if your code can't meet all of the boldface conditions... in the real world, you can't simplify the system requirements to meet the deficiencies of your coding language)
"Are you hungry? I haven't eaten since later this afternoon." -- Primer