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?

11 of 757 comments (clear)

  1. Re:Write-only code. by Anonymous Coward · · Score: 5, Interesting

    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.

  2. Re:Write-only code. by mellon · · Score: 5, Interesting

    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.

  3. Machine Beauty. by TechyImmigrant · · Score: 4, Interesting

    In 1998 David Gelernter wrote a book that effectively argues that elegance and beauty in engineering are essential features that lead to benefits beyond the merely aesthetic.

    He is still right.

    The 'elegant' and 'concrete' example in TFA is ugly and hard to follow, even with plenty of understanding of lambda expressions and languages that offer them. I have other, better high level language options and other, better low level language options. C++ fails the test. C++ is not for me.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  4. Re:How much is it C++ and how much the compilers? by david.emery · · Score: 5, Interesting

    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?"

  5. Re:Python/C++ Combo by Dan667 · · Score: 4, Interesting

    why not Python and ANSI C? Then you have productivity and glue code of Python and the raw speed of C without all the clutter.

  6. Re:Write-only code. by Anonymous Coward · · Score: 5, Interesting

    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.

  7. Re:Write-only code. by johanw · · Score: 4, Interesting

    I usually use C++ as "C with classes". No fancy stuff like STL or Lambda expressions. That works well, and most companies where I've worked use C++ that way.,

  8. Re:Python/Fortran Combo by goombah99 · · Score: 4, Interesting

    I have discovered late in the game that Python + Fortran is almost magical. It's better than Python C++. when you are needing fast algorithms or code close the metal (SIMD or GPU) then fortran provides all the muscle that you need without all the baggage of c++. You offload complex class and memory allocation to the python.

    The amazing thing I really like about the fortran is that it compiles so damn fast compared to C++ that it's easy to write a python program that generates optimized fortran and then compile it at run time rather than simply pre-compile a C++ library to include. The fortran is cleaner looking and its hard to make typos. The limits and ugly bits of fortran are pretty much not a concern since those chores can be offloaded to the python.

    --
    Some drink at the fountain of knowledge. Others just gargle.
  9. Re:Write-only code. by spiralx · · Score: 4, Interesting

    It's both. Type import this from the interpreter, and you'll get this:

    The Zen of Python, by Tim Peters

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!

    While it doesn't always manage it, if you read the discussions and PEPs relating to the language's design it's clear that the idea of a "Pythonic" way of doing things is one of the top considerations.

  10. Re:Aren't all (but one) popular languages like thi by Rei · · Score: 5, Interesting

    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
  11. Re:Write-only code. by Rei · · Score: 5, Interesting

    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