Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Programming

Was Linus Torvalds Right About C++ Being So Wrong? 757

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?
This discussion has been archived. No new comments can be posted.

Was Linus Torvalds Right About C++ Being So Wrong?

Comments Filter:
  • Write-only code. (Score:5, Insightful)

    by mellon ( 7048 ) on Tuesday March 10, 2015 @04:49PM (#49228079) Homepage

    The problem with C++ is that it's way too easy to write write-only code, because the language has so many features that nobody but language experts understand all of them. So we all program in different dialects, and then scratch our heads when we read other peoples' code.

    • Re:Write-only code. (Score:5, Interesting)

      by Anonymous Coward on Tuesday March 10, 2015 @04:56PM (#49228143)

      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.

      • Re:Write-only code. (Score:5, Interesting)

        by mellon ( 7048 ) on Tuesday March 10, 2015 @04:59PM (#49228165) Homepage

        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.

        • Re:Write-only code. (Score:5, Interesting)

          by Anonymous Coward on Tuesday March 10, 2015 @05:36PM (#49228505)

          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.

          • Re:Write-only code. (Score:5, Informative)

            by Darinbob ( 1142669 ) on Tuesday March 10, 2015 @06:46PM (#49229149)

            Right now I'm doing just C and assembler (and the occasional scripting in something else). Sometimes it feels a bit archaic compared to a stripped down C++ style I'm more used to, but on the other hand there just aren't as many political fights over style so it's less stressful. The interesting thing about C is that newer standards don't tend to lots of new and experimental features, which is sort of the norm with C++. C tries to be stable.

            Also a big part of my job when doing C++ was decoding the obtuse error messages for coworkers, and that almost never happens with C...

            • I found, after decades of experimentation, that simplicity and consistency beats everything else if you want to produce reliable software. Now, I use C exclusively just so I don't have to deal with multiple different ways to do something because the C++ standards committee got a bee in its bonnet about the latest hot new concept that first came out in 1959 and was forgotten until last year.

              The problem with possessing multiple ways to solve a problem is that every developer takes it as a personal challenge to find and use all the different ways. To make things easier I simply wrote a library containing those things that I usually need (sane string operations, c/line parsing, vectors, etc) and found that 90% of what you can do with X lines of fairly complex grammar in C++ can be done with around 1.5X of straightforward C grammer. I don't need the remaining 10% if it needs 300% cognitive effort to get.

              The library is here: Extended C library, libxc [sourceforge.net], so help yourself (BSD license)

              .

              Documentation is over here: PDF link, but html available [lelanthran.com], although the documentation on the website is out of date. If you download the library source you get the full up-to-date docs.

              • by serviscope_minor ( 664417 ) on Wednesday March 11, 2015 @09:09AM (#49232681) Journal

                because the C++ standards committee got a bee in its bonnet about the latest hot new concept that first came out in 1959 and was forgotten until last year

                Give one example of that ever happening. The C++ standards committee is notoriously conservative which is why the language evolves so slowly. This comes across as you just making shit up when you haven't got a clue.

                The problem with possessing multiple ways to solve a problem is that every developer takes it as a personal challenge to find and use all the different ways.

                That might be *your* problem but it isn't mine. Every decent place (staffed by true scotsmen of course) with project teams has things like coding standards and code reviews.

                If your developers are committing crap code to the mainline then the trouble is that (a) your developers and (b) your process sucks. The thing is it will suck in any language.

                The library is here: Extended C library, libxc, so help yourself (BSD license)

                OK, I'll bite.

                Well, if you think having XVEC_DEREF(some_vector, i, float) for resisable arrays but array[i] for builtin ones is better than having array[i] for both, well, then I guess we're just on completely different pages here.

                The thing is there's massive syntactic overhead to your code. And the overhead is more like 1000% not 150%.

                vector<float> = { 1.1, 2.2, 3.3, 4.4, 5.5, 6.6, 7.7, 8.8, 9.9};

                works perfectly in C++, whereas that's 10 lines of C code!

                And I was wondering how it worked underneath, and I had to dig into the code. So you're storing pointers to the elements, not the elements themselves! I never even realised that. Wow, so that means you can't even do:

                xvector_ins_tail(tfar, &1f);

                You have to do:

                some_float_which_has_the_same_scope_as_tfar_and_is_never_reused = 1;
                if(!xvector_ins_tail(tfar, &some_float...))
                { //Do something error related here //probably a longjmp or goto. //Don't forget to free all that memory!
                }

                versus:

                tfar.push_back(1.5);

                It also means you're in nightmare memory management from hell since you now have to manage all those bits of memory by hand.

                It *also* means that you have no memory locality since it's a big array of pointers, so performance will almost certainly be bad as well.

                The equivalent C++ code to your xvector/main.c is something like:

                vector<float> sfar = {1.1, 2.2, ...};
                 
                for(const auto& f:sfar)
                  cout << f << endl;
                 
                eg_t eg[] = {...};
                 
                vector<eg_t> teg, sub;
                for(const auto& e:eg)
                  eg_t.push_back(e);
                 
                for(auto e:teg)
                {
                  e.i += 2;
                  e.f -= 5.0;
                  sub.push_bach(e);
                  cout << "Returning " << e.i << " // " << e.f << endl;
                }
                 
                //Well, the nativea bit is basically already working in the C++ code since internally, std::vector uses a native array

                And that gets us to line 90 or so. There's more, but you missed the error checking for if something isn't found in the xvector. It also took me a while to verify that all the allocations are matched by the respective free. It would be nearly impossible to be sure for less trivial code.

                So, I'm not convinced you've made a case for C over C++ here.

        • by Anonymous Brave Guy ( 457657 ) on Tuesday March 10, 2015 @05:37PM (#49228513)

          This is all true, but I'm not sure how it's any different to almost any other popular language.

          Java and C# have also evolved a lot of new language features in recent years. For many types of software, the way the code looks will also be heavily influenced by which libraries and frameworks are used in that project's stack.

          It's the same story for web development. We have different flavours of JavaScript (ES5 in most browsers today, but ES6 just around the corner and supporting a wider range of programming styles), Python (2 vs 3), and so on. And with these more dynamic languages, the style is often even more guided by a framework if you're using one.

          Even if you're not using pervasive third party frameworks or libraries, any project of non-trivial size is going to adopt its own conventions and build its own abstractions to suit its particular needs, and then the rest of its code will again become its own dialect written in terms of those conventions and abstractions.

          In fact, I can't think of any mainstream language except for C that doesn't suffer from the "dialect" problem to some extent. And that's because C is a 20th century language in a 21st century world, so lacking in expressive power that it can't support any of these modern, high-productivity development styles and abstraction tools. Its ubiquity, portability and simplicity are assets, but they are effectively its only redeeming features in 2015, and as time goes by it will be necessary for fewer and fewer projects to choose C for those reasons.

          "There are only two kinds of languages: the ones people complain about and the ones nobody uses." -- Bjarne Stroustrup

          "If you attack a tool based primarily on not liking the people who use it, you're still just a bigot, no matter how famous you are." -- Anonymous Slashdot poster

      • Re:Write-only code. (Score:5, Interesting)

        by johanw ( 1001493 ) on Tuesday March 10, 2015 @05:43PM (#49228563)

        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.,

        • Re:Write-only code. (Score:5, Interesting)

          by Rei ( 128717 ) on Tuesday March 10, 2015 @07:36PM (#49229595) Homepage

          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)

          • Re:Write-only code. (Score:5, Informative)

            by spitzak ( 4019 ) on Tuesday March 10, 2015 @08:36PM (#49229983) Homepage

            The sample code will copy a and b twice, once to put them in the lambda closure, and then to pass them as arguments to do_something. Some may consider this wasteful (the easiest fix is to modify do_something to take the values as const references).

            This is the general problem with C++, in that the shortest code is often the slowest. Adding const references to the declaration of do_something would remove the useless extra copy. The slowness is visible in C, where you would probably allocate a structure containing the copy of a and b, and have pthread_create call a function that copies them to the arguments to do_something and calls it, then deletes the temporary structure. This is equivalent to what the C++ compiles into but all the inefficiency is visible. This is the primary complaint about C++ verses C.

            PS: I use C++ all the time and prefer it over C. But you do require a good knowledge of what it turns into, often stated in a pseudo-C, to figure out how and why things work and why slight variations (try using [&] instead of [=] in your lambda!) break in horrific ways.

            • by Rei ( 128717 ) on Tuesday March 10, 2015 @09:26PM (#49230361) Homepage

              The sample code will copy a and b twice, once to put them in the lambda closure

              Only without optimization flags enabled. Otherwise the lambda will be inlined in most cases.

              This is the general problem with C++, in that the shortest code is often the slowest

              Compared to what alternative C algorithm? Still waiting here.... ;)

              Beyond that, that's not how you optimize a program. You don't try to optimize the heck out of every last line; that's a recipe for an unmaintainable mess that's not actually that fast. You write clean, organized code, you profile it, and then you optimize where the profiling data tells you that you can make the biggest improvement. Trying to be "clever" and outsmart the compiler with every line of code "in the interest of performance" is how spaghetti code gets made

              The slowness is visible in C, where you would probably

              To reiterate my first post:

              Show me the code (emphasis: show me actual code, don't just say "... this is how I'd do it" and a rough description

              Yes, I knew exactly that people like you would come in and try to pass off a rough description as an implementation. The reality is that the implementation is such an utter, bug-prone PITA in C (compared to a trivial command in C++) that most people don't even bother. Which means that code gets underthreaded, which means that it performs terrible and is prone to lockups.

              Threading is of course just the start here...

              • Re:Write-only code. (Score:5, Informative)

                by spitzak ( 4019 ) on Tuesday March 10, 2015 @10:55PM (#49230689) Homepage

                The sample code will copy a and b twice, once to put them in the lambda closure

                Only without optimization flags enabled. Otherwise the lambda will be inlined in most cases.

                BZZT! Wrong! Think: what happens if a and b are local variables and the function creating the thread returns before the lambda runs? They must be copied to somewhere that is not destroyed by the caller returning. That copy is not in the correct location because they are created before the thread stack, so another copy is unavoidable. The only way to fix it is to make do_something take const references. Though it is true that if do_something was inline it would probably fix it.

                Show me the code

                Yes it is ugly and I never claimed otherwise. The problem is that C++ compiles into the equivalent of this and it is hidden behind the scenes. Here is is pretty obvious that I must not pass a pointer to a or b, not so clear in C++:

                #include <pthread.h>
                #include <stdio.h>
                #include <malloc.h>
                #include <unistd.h>

                void do_something(int a, int b) {
                    printf("do_something %d %d\n", a, b);
                }

                typedef struct {
                    int a, b;
                } lambda_args;

                void* lambda_run (void *p) {
                    lambda_args* v = (lambda_args*)p;
                    do_something(v->a, v->b);
                    free (v);
                    return 0;
                }

                void thread_do_something (int a, int b)
                {
                    lambda_args* v = (lambda_args*)malloc(sizeof(lambda_args));
                    v -> a = a;
                    v -> b = b;
                    pthread_t thread;
                    pthread_create (&thread, 0, lambda_run, v);
                }

                int main()
                {
                    thread_do_something(1, 2);
                    thread_do_something(3, 4);
                    sleep (1);
                    return 0;
                }

                • Re:Write-only code. (Score:5, Informative)

                  by Rei ( 128717 ) on Wednesday March 11, 2015 @06:42AM (#49232131) Homepage

                  BZZT! Wrong! Think: what happens if a and b are local variables and the function creating the thread returns before the lambda runs?

                  BZZT! Wrong yourself! And let this be a lesson to you to not be so haughty when replying. What you describe never happens. The lambda is built synchronously, but called asynchronously.

                  To prove it, try out the following code:

                  #include <iostream>

                  void do_something(int a, int b) { std::cout << a << b; };

                  int main(int argc, char** argv)
                  {
                  int a = 12, b = 23;
                  ([=](){ do_something(a,b); })();
                  }

                  Compile it with "g++ --std=c++11 -S -O4" and check out the .S file (compare it to the -O0 version too). In the -O4 version you'll see the following:

                  main: .LFB1262:
                  leal 4(%esp), %ecx .LCFI6:
                  andl $-16, %esp
                  pushl -4(%ecx)
                  pushl %ebp .LCFI7:
                  movl %esp, %ebp
                  pushl %ecx .LCFI8:
                  subl $12, %esp
                  pushl $23
                  pushl $12
                  call _Z12do_somethingii

                  You see that? It's pushing the local values directly onto the call stack. There is no intermediary step for the lambda.

                  Okay, so maybe my test case was too simple? Let's complicate it.

                  #include <iostream>
                  #include <stdio.h>

                  void do_something(int a, int b) { std::cout << a << b; };

                  int main(int argc, char** argv)
                  {
                  int a, b;
                  scanf("%d", &a);
                  scanf("%d", &b);
                  std::cout << 34;
                  #if 0
                  ([=](){ do_something(a,b); })();
                  #else
                  do_something(a,b);
                  #endif
                  }

                  Try it again with -O4 with the if set to 0 or 1 and compare the two versions together. You'll see that they're exactly the same. In both cases, main is:

                  main: .LFB1262:
                  leal 4(%esp), %ecx .LCFI6:
                  andl $-16, %esp
                  pushl -4(%ecx)
                  pushl %ebp .LCFI7:
                  movl %esp, %ebp
                  pushl %ecx .LCFI8:
                  leal -16(%ebp), %eax
                  subl $28, %esp
                  pushl %eax
                  pushl $.LC1
                  call scanf
                  popl %eax
                  leal -12(%ebp), %eax
                  popl %edx
                  pushl %eax
                  pushl $.LC1
                  call scanf

            • This is the general problem with C++, in that the shortest code is often the slowest.

              Well, that's better than the general problem when the shortest code in C normally leads to a crash or a memory leak. Yep, if you copy structs-with-pointers around like containers willy-nilly you soon screw up and get a leak or a segfault.

              The other thing of course is that you have 1 line ot find the slowness, not 30 as in the C code.

          • by Uecker ( 1842596 )

            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)

            Somebody else answered this already and I prefer the C solution. But this example seems rather contrived anyway. Let's do something much simpler: Write a matrix multiplication routine for arbitrary-sized matrices which is not allowed to use the heap.

            void mat_mul(int A, int B, int C, double out[A][C], double in1[A][B], double in2[B][C])
            {
            for (int i = 0; i A; i++) {
            for (int k = 0; k C; k++) {
            out[i][k] = 0.;

          • (Don't bother responding if your code can't meet all of the boldface conditions...

            Challenge accepted, see here for my first go that satisfies all the bolded conditions. Any further conditions you impose now will make you look even more like an ass than you already do for posing such a fanboyism challenge. Note well: there are literally only four lines of code to achieve this - I posted the other lines to give the readers some context.

            struct foo_t {
            size_t one;
            size_t two;
            };

            void *do_something (struct foo_t *array)
            {
            printf ("%zu, %zu\n", array[0].one, array[1].two);
            }

            #define THREAD_CREATE(fptr, type, a, b) do {\

            // Start of challenge
            type array[] = { a, b };\
            pthread_t tmp;\
            pthread_create (&tmp, NULL, (void *(*) (void*))do_something, array);\
            pthread_detach (tmp);\

            // End of challenge, you're welcome
            } while (0)

            int main (void)
            {

            ...
            struct foo_t first, second;
            ...
            THREAD_CREATE (do_something, struct foo_t, first, second);

            ...
            ...
            }

            in the real world, you can't simplify the system requirements to meet the deficiencies of your coding language)

            As you can see above, no deficiency found - in the actual real world, as opposed to the one populated by inexperienced fanboys like yourself, the above solution would not be discarded from the solution set if it meant changing the codebase from C to C++.

            You can now be an adult about the whole thing, accept that what you can do in C++ can be done in a readable manner in C as well. I don't think you will, though - I have a feeling you'll come up with another idiotic "C++ can do this, can C do this?" question, at which point I will once again be happy to smack you in the face with a solution like I did just now.

            Consider yourself schooled.

    • by Anonymous Coward on Tuesday March 10, 2015 @04:57PM (#49228149)

      This is a potential problem with every single programming language ever. No exceptions. C is somewhere in the middle with that risk, but it is no where near the worst. I'd give that medal to Perl.

      • by mellon ( 7048 )

        True, but for example while Scheme is highly extensible, there isn't a lot of really obscure syntax, nor is there a preprocessor. Anything that's Turing complete can develop widely divergent dialects, but C++'s dialects are notoriously obscure.

      • Re: (Score:3, Insightful)

        by Penguinisto ( 415985 )

        This is a potential problem with every single programming language ever. No exceptions. C is somewhere in the middle with that risk, but it is no where near the worst. I'd give that medal to Perl.

        The more powerful the language, the more it's like a loaded gun: You can use it responsibly and do amazing things with it, or you can put a bullet through your foot with it. Choice is yours... and the closer you get to bare metal with the language, the greater the chance of lead meeting foot at high speed.

        • The more powerful the language, the more it's like a loaded gun: You can use it responsibly and do amazing things with it, or you can put a bullet through your foot with it. Choice is yours... and the closer you get to bare metal with the language, the greater the chance of lead meeting foot at high speed.

          Oddly, that brings to mind the famous quote from Bjarne Stroustrup himself...

          "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

          I've only briefly looked at C++, but when I did, I understood what he meant. C++ lets you do some very complex, powerful and abstract things compared to C, but even in the small amounts I learned (and have since forgotten) you could see the potential for an overly confident smartass to misuse or fail to understand t

    • by Carewolf ( 581105 ) on Tuesday March 10, 2015 @04:58PM (#49228161) Homepage

      The problem with C++ is that it's way too easy to write write-only code, because the language has so many features that nobody but language experts understand all of them. So we all program in different dialects, and then scratch our heads when we read other peoples' code.

      Less so than C, especially as used in the kernel. Seriously read some of the Linux kernel and compare it with any good C++ project. The kernel loses BADLY. The manually implemented virtual classes are not pretty and not type safe, and neither are all the ugly macros needed to do things that would safe, automatic and easy to read in C++.

      • by mellon ( 7048 )

        I don't think you actually mean "virtual classes" here. But yeah, if you have to implement classes in C, maybe you should have used C++. One of C++'s problems is that it builds on C, though, so the fact that you can do some things, particularly classes, better in C++ than in C shouldn't be a surprise: that's the itch they were scratching.

        • I don't think you actually mean "virtual classes" here. But yeah, if you have to implement classes in C, maybe you should have used C++. One of C++'s problems is that it builds on C, though, so the fact that you can do some things, particularly classes, better in C++ than in C shouldn't be a surprise: that's the itch they were scratching.

          I mean virtual tables, which is the implementation side of virtual classes. The kernel uses virtual tables extensively to describe interfaces of modules and especially drivers.

          • by Dwedit ( 232252 )

            Sounds like that goes back to the "lack of standard ABI" problem. C lets you specify exactly what you want explicitly, but C++ has no consistent ABI, you get different results depending on which compiler you use.

            • Re:Write-only code. (Score:4, Informative)

              by Carewolf ( 581105 ) on Tuesday March 10, 2015 @06:31PM (#49229021) Homepage

              Sounds like that goes back to the "lack of standard ABI" problem. C lets you specify exactly what you want explicitly, but C++ has no consistent ABI, you get different results depending on which compiler you use.

              Not anymore. At least not on Linux. Intel wrote a C++ ABI for IA64 (Itanic), since it was the first of its kind it got adopted to a defacto ABI for all other architectures as well. This is what g++ has been using for over a decade, and what every other compiler is mimicking to stay g++ compatible.

              Even a failed architecture can sow the seeds for good things in the open source world.

      • by sjames ( 1099 ) on Tuesday March 10, 2015 @05:28PM (#49228423) Homepage Journal

        Actually, the kernel code is quite clear and understandable to any decent C programmer. I find it hard to consider it losing BADLY to anything.

        Note that C++ isn't necessarily type safe either. It's not at all difficult to cast an object pointer to the wrong type and crash. It's no harder than it is in C.

        • Casting (Score:3, Insightful)

          Casting is telling the compiler to do what you want. It's like saying "Shut up! I know what I'm doing, this thing is a XY pointer, even if you can't figure it out yourself."

          In every language (which supports casting) you can make an error while casting by claiming something that isn't correct. Surprise!

    • by loonycyborg ( 1262242 ) on Tuesday March 10, 2015 @04:59PM (#49228175)
      I definitely disagree here. All features of C++ have their uses and it's possible and necessary to master them all. This language is focused on getting the job done. Thus some of its design decisions don't look very nice. But it's the most usable language in its niche.
    • by KermodeBear ( 738243 ) on Tuesday March 10, 2015 @05:02PM (#49228219) Homepage

      The same applies with Perl. And PHP. And Java. And Go. And Ruby. And Python. And Javascript.

      I've also seen good C/C++, PHP, Java, Python, etc.

      You can write crappy convoluted code that uses odd, unusual frameworks and features in every language. It isn't the fault of the language - it is the fault of the people (ab)using it.

      • One of the nice things about Python is the very concrete idea of what is and isn't "Pythonic". I've never had too much difficulty jumping right in to something written in Python and having a good idea of what's going on.
      • Re:Write-only code. (Score:4, Interesting)

        by Pieroxy ( 222434 ) on Tuesday March 10, 2015 @05:32PM (#49228461) Homepage

        Are you comparing the complexity of Java vs C++ (as a language, not as a runtime)? Are you kidding?

        You can write convoluted code in any language, this is true. But C++ code can be made UNREADABLE as well as convoluted. In Java, there is only the one way of writing things. You can architect them differently if you want, but there's usually one way to write them. In C++, you have a hundred. THIS is the problem with C++. And let's not even talk about macros which is one more way to write things. You can actually write your whole program only through macros. Macros are turing-complete. They're just a language inside the language... This is pure madness.

        • C++ templates are also Turing-complete at compile time.

          When I tried learning a bit of LISP, the thing that struck me was that its metaprogramming language is also the runtime language, and I like that very much.

    • by goombah99 ( 560566 ) on Tuesday March 10, 2015 @05:25PM (#49228401)

      C itself has so many pitfalls. For the best tour review the underhanded C contest. "features" like automatic concatenation of consecutive character strings means that if you leave out a comma in a list, the adjacent array element entries are concatenated rather than throwing a syntax error. That list will now not match the declared array size (one short, so there's a null or random pointer in the last element) but the compiler allows initialization listed mismatched to the array sizes. Character strings have to be declared one longer than the initialization string length (room for the unstated \0) but are accepted by the compiler if they don't giving an unbounded string length.

      it's mind boggling to realize that
      int (*int)[20];
      int *int[20];
      are different things.

      the number of different ways an array argument in a function can be written makes code hard to grasp: is it a pointer, an array, a reference? many work alike but then fail in different ways.

      The most common of all pitfalls and hard to read codes are the in-line initializations that pop up in function arguments and what not. this leads to classic blunder of writing = when you mean ==.

      Perhaps the most insane thing is that If you declare an external function with the wrong prototype then any mismatch in the argument count leaves or takes something off the stack. Holy cow..... I mean what the hell? Why would any language ever ever ever let you leave a orphan argument on the stack, or worse pop one off that was not yours? This is very useful for the underhanded C folks however.

      While I know there's little love for fortran, it's worth noting that none of those things is even possible in Fortran, so its an existence proof that there's not any necessity for those to exist and that it doesn't limit the power of the language to remove them. It's very fair to say that no simple typo will ever compile in fortran (yes very complicated offsetting typos can compile).

      • gahh. I just typoed my example!!! oops.
        int (*foo)[20];
        int *foo[20];

        But I bet that error would even compile!

        • by slew ( 2918 )

          gahh. I just typoed my example!!! oops.
          int (*foo)[20];
          int *foo[20];

          But I bet that error would even compile!

          yeah but in principle that's not much different than

          t = x+y*z; different than
          t = (x+y)*z;

          Except that people mostly remember algebra precedence. Sure 'c' precedence rules and postfix syntax has its warts (consider the typedef function), but your example isn't one of them...

          For me the truly annoying things about C vs Fortran, is that C basically allowed to ignore your parenthesis from a equi-precedence, computational point of view where (x+y)+z != x+(y+z); Also, its definition of sequencing is kind of brok

          • (x+y)+z != x+(y+z); - correctly evaluates to false in C, the parentheses can safely be ignored because they are redundant and make no difference to the outcome.
            x = x++; is basically undefined - How so? The code increments x, the "x=" part is harmless, again you are using redundant code that any halfway competent C programmer would not write in the first place.
            I've been making a good living from C/C++ for 25yrs, I don't see your "problems", and I can't imagine the "workarounds" to be anything other than
  • Almost got me (Score:5, Insightful)

    by halivar ( 535827 ) <bfelgerNO@SPAMgmail.com> on Tuesday March 10, 2015 @04:51PM (#49228095)

    I always get halfway through a Nerval's Lobster summary before my anger/indignation/smug validation gives way to the sad realization that Dice has trolled me yet again.

  • Full Disclosure (Score:5, Informative)

    by mu51c10rd ( 187182 ) on Tuesday March 10, 2015 @04:54PM (#49228113)

    Could we stop having Dice articles submitted by Nerval's Lobster? Why not fully disclose that the story was submitted by the corporate parent of Slashdot?

    • Mod parent up (Score:5, Informative)

      by amaurea ( 2900163 ) on Tuesday March 10, 2015 @05:24PM (#49228387) Homepage

      I just looked through Nerval's Lobster's last 15 contributions. All were article submissions, Nerval's Lobster doesn't appear to comment on anything. Here's the list:

      • Was Linus Torvalds Right About C++ Being So Wrong? [Dice]
      • Do Tech Companies Ask For Way Too Much From Job Candidates? [Dice] [Hiring]
      • 'Chappie': What It Takes to Render a Robot [Dice]
      • Demand for Linux Skills Rising This Year [Dice] [Hiring]
      • Who's Afraid of Android Fragmentation? [Dice]
      • H-1B Visas Proving Lucrative for Engineers, Dev Leads [Dice*] [Hiring]
      • In Space, a Laptop Doubles As a VR Headset [Dice*]
      • What Does It Mean to Be a Data Scientist? [Dice]
      • Which Freelance Developer Sites Are Worth Your Time? [Dice*] [Hiring]
      • JavaScript, PHP Top Most Popular Languages, With Apple's Swift Rising Fast [Dice*]
      • Building a Good Engineering Team In a Competitive Market [Dice*] [Hiring]
      • What Makes a Great Software Developer? [Dice*] [Hiring]
      • The Highest-Paying States for Technology Professionals [Dice] [Hiring]
      • What Will Google Glass 2.0 Need to Actually Succeed? [Dice*]

      Every single one of them is from dice, though only a few of them actually make that explicit (the non-explicit ones are marked [Dice*]. A large fraction of them are related to human resources and hiring people, which I've marked [Hiring]. So its like Nerval's Lobster is using Slashdot as advertising and recruitment channel for Dice.

      The average quality of these submissions was very low in my opinion - lots of vacuous pointy-haired-boss buzzword stuff. Very un-nerdy. How did these get through submission moderation? Were they even subjected to it?

  • by pla ( 258480 ) on Tuesday March 10, 2015 @04:55PM (#49228121) Journal
    / Grabs popcorn
    // Dons asbestos armor
  • No (Score:2, Insightful)

    by Anonymous Coward
    Linus was not going overboard. In this rare instance, I'd argue he hasn't gone far enough.
  • by bhcompy ( 1877290 ) on Tuesday March 10, 2015 @04:59PM (#49228171)
    The ability to fuck it up is a good thing, because there's a spectrum, and you can also knock it out of the park.
  • by fph il quozientatore ( 971015 ) on Tuesday March 10, 2015 @04:59PM (#49228173) Homepage
    What comes next, a thread on "is Emacs better than Vi"?
  • Ahhhh, C++ (Score:3, Insightful)

    by segedunum ( 883035 ) on Tuesday March 10, 2015 @04:59PM (#49228181)
    Although the language itself isn't truly, truly bad, the only thing that made it tolerable was a library like Qt. STL and Boost are so shocking it isn't even funny, as well as the attitude amongst many that they are some kind of 'standard'. That's where C++ really did go off the rails.
    • Re:Ahhhh, C++ (Score:5, Insightful)

      by gnupun ( 752725 ) on Tuesday March 10, 2015 @05:11PM (#49228283)

      Although the language itself isn't truly, truly bad,

      Any language that allows the programmer to override the '=' operator is truly, verily, bad. That makes the language over-programmable and a write-only language when trying to maintain other developer's code. Java may have fewer features, but that doesn't stop the developers from getting stuff done.

      • Re:Ahhhh, C++ (Score:4, Interesting)

        by crunchygranola ( 1954152 ) on Tuesday March 10, 2015 @05:48PM (#49228607)

        Any language that allows the programmer to override the '=' operator is truly, verily, bad.

        This is, to my mind, the most fundamental problem with C++: it is impossible to look at a page of code in isolation and know what it does, with confidence. Any of the operators could have been redefined to do anything. This is not a theoretical problem, I encountered a code base of horrors that a nerd who though he was God's gift to nerd-dom dreamed up, which had numerous standard operators reassigned to make the code he wrote "look elegant". It was impossible to analyze or maintain.

        When the meaning of a simple programming construct is indeterminate, the language that supports it has failed disastrously.

      • by Yunzil ( 181064 )

        Java may have fewer features, but that doesn't stop the developers from getting stuff done.

        This is a stupid argument. You could just as easily say, "Assembly language may have fewer features, but that doesn't stop the developers from getting stuff done."

  • by Rhyas ( 100444 ) on Tuesday March 10, 2015 @05:01PM (#49228195) Journal

    Need the ability to moderate an entire Article/Summary as Clickbait or Troll.

  • Python/C++ Combo (Score:5, Insightful)

    by EmperorOfCanada ( 1332175 ) on Tuesday March 10, 2015 @05:02PM (#49228211)
    I have read maybe 1 billion articles about language X being better than language Y and in many cases it is pure religious fanaticism; someone has committed to a language and now justifies that commitment with zealotry. A very common refrain about any given language is how many people write poor code in that language. This argument is often reserved to support the more "sophisticated" languages. For instance it is pretty much a gold medal sport to crap on PHP; and yes there is lots of terrible PHP which probably stems from the fact that it is often someone's first language and that someone is self teaching.

    Then other languages are looked at as toy languages by those who resent them, Python would often be a victim here.

    Then there are the wonderful charts of speed which in theory would justify everyone using ASM optimized to their CPU.

    But for me it is not one language but a pairing that has caught my heart. Python and C++ do just about everything I want. Python is just so damn productive. Then I use C++ for where Python falls down on speed or the environment itself is not conducive to C++ (embedded and multi-platform Mobile).

    But to answer his cry about people over-engineering things with silly STL uber inheritance type crap. That is where oddly enough the zealots of C++ are their own worst enemies. They love C++ so much they are giving it a bad name. Many people use STL in some purist way that completely blows Keep It Simple Stupid out of the water.

    But I really do hold a special revulsion for anyone who claims that their language "Enterprise" which translates to me as so shitty that nobody will notice that most of your drone developers are also shitty.
    • Re:Python/C++ Combo (Score:5, Interesting)

      by Dan667 ( 564390 ) on Tuesday March 10, 2015 @05:33PM (#49228475)
      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.
    • I'd rather work with skilled programmers in assembly than lousy programmers in (whatever amazing language you have).

      It's the programmers that matter, not the language.
      • Yup. Fully agreed. That is why enterprise languages exist. They aren't build for coding they are the devil's tools for building the 10th ring of hell (still under construction, 90% done, next milestone won't be missed just as long as that milestone is a report on why they are missing all the milestones)

        And who is sent to this coding hell? Crappy programmers.
    • by goombah99 ( 560566 ) on Tuesday March 10, 2015 @05:46PM (#49228591)

      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.

    • by radtea ( 464814 )

      But for me it is not one language but a pairing that has caught my heart.

      I'm in the same boat, with the same languages. Python for convenience, C++ for speed. I also use C for really low level embedded (PIC) stuff, but that's it.

      This combination gives me the optimal mix of portability and power for the problem domains I'm interested in, and at this point I don't see any reason to leave C++ for anything else. The big trick is to adopt and strictly adhere to a set of reasonable coding standards that keeps you from doing all the stupid things the language lets you do.

      C++ demands a

  • by RailGunner ( 554645 ) * on Tuesday March 10, 2015 @05:03PM (#49228221) Journal
    If you care about performance, the ability of C++ to "run on the iron" is a valuable tool to have in your arsenal. Add in inline assembler, and IF YOU KNOW WHAT YOU'RE DOING you can write blazing fast code in C++ and still provide a sensible code architecture.

    There's no sense in blaming the language for the abuses developers have written -- you might as well indict English for the horrible spelling and grammar of many Americans...

    If you know what you're doing, C++ is a terrific, powerful language suitable for a plethora of projects. On the other hand, if you don't know what you're doing, well, I guess there's Visual Basic or C#.
  • Machine Beauty. (Score:5, Interesting)

    by TechyImmigrant ( 175943 ) on Tuesday March 10, 2015 @05:07PM (#49228251) Homepage Journal

    In 1998 David Gelernter wrote a book [amazon.com] 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.

  • by Frobnicator ( 565869 ) on Tuesday March 10, 2015 @05:23PM (#49228377) Journal

    Linus is doing systems level work. At systems level work, there are a lot of mediocre and bad programmers who use the common language of C++. Those who know c well are unlikely to be the mediocre and bad programmers.

    That is really a truism across all fields and languages.

    In the business world with business logic, there are a lot of mediocre and bad programmers who use the common language of Java. You can filter out many of them by adding a skill requirement of some other less-used languages inside that realm of business software development.

    In a field where everyone is doing Ruby development and you don't want mediocre/bad Ruby programmers? Require them to also demonstrate proficiency in another language.

    In a field where everyone is using C#? Require them to also demonstrate proficiency in C++ or some other language.

    If you only require a single thing you can get unskilled individuals with only a single skill. If you require multiple skills you are more likely to get more talented individuals, since the talented, higher producers tend to pick up a wide range of skills.

  • C++ is hard (Score:5, Informative)

    by Prien715 ( 251944 ) <<moc.liamg> <ta> <epopcitsonga>> on Tuesday March 10, 2015 @05:25PM (#49228399) Journal

    C++ was the first popular fast OO language. As such, there's a lot of confusing cruft left behind. Consider overloading the && operator or || operators. You should never do this*. But someone will come along and do it anyway. You can't get rid of the feature because of backwards compatibility and yet it's miserable. We can go down the list from polymorphic arrays to calling virtual functions during constructors. All things one should never do, but the language keeps them there for the sake of backwards compatibility.

    Languages like Java fix some of these problems by explicitly not allowing operator overloading (which is heavy-handed) but enforces some readability.

    As others have said, using good 3rd party libraries like Qt makes the language tolerable, but in the legacy applications I've supported, there's no shortage of programming faux pas made possible by the language (like assumptions about the order of static variable destructors -- which is compiler dependent). As a programmer, it can be fun and productive since simply using the better parts of the language can make programs easy to write and read. As a maintainer, it's a smorgasbord of bad programming practices which the language makes no attempt to prevent.

    That said, Linus really likes the new version of Subsurface based on Qt [google.com]. So there;)

    * Scott Meyers More Effective C++ p.35

  • by Marginal Coward ( 3557951 ) on Tuesday March 10, 2015 @05:25PM (#49228403)

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

    That seems like a strange statement coming from someone who is one of the best programmer's on the planet - and who works closely with some of the others.

    I don't disagree that C++ provides a lot of rope for substandard programmers to hang themselves with (and I've seen that done by someone who created layer upon layer of useless classes), but I assume Linus Torvalds doesn't hang out with too many "substandard programmers." So what's he afraid of?

    Although C++ may not be for everybody, and it's far from ideal, I think it's generally a pretty good solution for the problems it's trying to solve. And it's not just me: it's notable that it dominates its niche as the primary C-inspired, object-oriented, compiled language.

  • by Todd Knarr ( 15451 ) on Tuesday March 10, 2015 @05:33PM (#49228487) Homepage

    The major problem with C++ is that it's popularity means there's more crap code written in it by bad programmers than any other language. But, to borrow from a quote, a bad programmer can write bad C++ in any language. I've had plenty of experience with bad programmers and bad code, and the problems rarely stemmed from the language used. They usually stem from the programmer not understanding the language or the environment and from an all-too-common mule-headed desire to design their part of the software the way they want it to work rather than in a way that fits with the rest of the software. Languages where this isn't a problem are typically new enough that there's only been one "right way" to do things taught. C++ is old enough that there's a variety of approaches built up over time, leading to the problem.

    As for C++ being so popular, that's because well-written C++ can beat most other languages in performance. I've learned one thing over the decades: good engineering in software is a great priority as a developer, but from the business side it's irrelevant. Business cares that it gets the correct results and it runs fast enough. It could be the worst Rube-Goldbergesque contraption under the hood, but as long as it gave the right results and performed like a Formula 1 car they'd be ecstatic. C++ makes it easy to achieve that in the complex software common in commercial environments.

  • by chaim79 ( 898507 ) on Tuesday March 10, 2015 @05:56PM (#49228699) Homepage

    This must be prefaced by mentioning that I have little experience with C++ code, the industry that I am in (Safety Critical Avionics software) absolutely refuses to use the language. In fact, the only thing I can really comment on are the reasons given to me as to why it is not used in this industry.

    Compiling repeatability
    Part of Safety Critical Avionics is that the binary must be perfectly re-creatable. At any time if an issue comes up someone must be able to rebuild the configuration used for compiling (versions, software packages, patches, etc.) and get a perfect match to the released binary, bit-for-bit perfect. Somehow most C++ compilers and libraries are unable to achieve this, using the same exact machine (no patches or changes) and compiling at a different time gives a different result. This has been demonstrated on several different compilers, using nothing other than standard libraries.

    Code-to-binary and structural coverage analysis
    For DO-178B Level-A software (paraphrase: "If this software fails, people die.") there is an analysis performed matching every line of code to a block of assembly, verifying that the compiler didn't add anything in that will cause issues. This prevents using some optimization options in C as that makes things too unreadable. However that also excludes C++ STLs and Boost libraries, as once you get into those libraries the traceability breaks down into impossibility very quickly.

    Internationalization
    On the side our company works on non-safety-critical software projects as companies need our help and we are looking for work. One of those side jobs is taking an application written over several years for a research facility and making it ready to be sold internationally. The project uses C++ and is converting X11 and Motif to QT, at the same time updating it to go from hard-coded English to strings that can be translated to multiple languages. The amount of cursing I hear from those engineers dealing with the internationalization of C++ far outweighs everyone else in the company on all other projects, apparently the design of the C++ language made many decisions that make such efforts very difficult.

    So, mostly hear-say but from trustworthy and knowledgeable people, which is why I rarely touch the language.

  • by LordZardoz ( 155141 ) on Tuesday March 10, 2015 @05:59PM (#49228729)

    Set aside for a moment about which programming language you like to use the most, and how much it upsets you that "People you Do Not Know also Do Not Like what You Like". Many of us are employed to work on projects we did not start. In most cases, you are not going to start a job and tell people 'Henceforth, all code shall now be implemented in the One True Language'.

    Assuming that, which language is going to get you paid the most and make you most employable?

    I am a game developer, and I have worked on consoles and currently on mobile games. I have used mostly C++. But I have had to work with pure C and C#. Being able to write good code in C++ is primarily responsible for me being employed.

    END COMMUNICATION

  • by hey! ( 33014 ) on Tuesday March 10, 2015 @06:41PM (#49229105) Homepage Journal

    Compared to C, sure. C was conceived in a spirit of pragmatic minimalism that's easy to love. I remember learning C from the K&R book back around 1980. That book was so thin it was practically a pamphlet next to books that taught you other languages. Everything about C was so neat, and trim, and cogent -- even the book everyone learned it from. That plus The Unix Programming Environment and perhaps Software Tools and you were cooking with gas.

    It's natural to compare C++ to C; the very name encourages you to do so. It was to conceived to dovetail and build upon C. But it was conceived with an almost diametrically opposite kind of philosophy. C chucked out all the precious features that designers were putting into languages in the late 60s and early 70s and went with a tiny set of proven useful features. C++ implemented every bell and whistle anyone had ever dreamed up for object oriented programming, which was largely an academic topic that was full of clever but impractical notions. Well, it turned out that a lot of those things like operator overloading and multiple inheritance weren't all that useful in the judgment of later language designers, but you can hardly blame Bjarne Stroustrup from knowing that in advance.

    It's practically impossible to overstate the practical success of C++. It took what was for most practicioners a theoretical idea (object oriented programming) and made it the way everyone programs by default. But you can't expect someone who loves C to love C++, which has almost none of the virtues that people admire in C.

  • STL (Score:5, Informative)

    by SoftwareArtist ( 1472499 ) on Tuesday March 10, 2015 @06:52PM (#49229215)

    You can argue about whether C++ is a horrible language (I lean toward "yes") in itself, but the libraries are what really push it over the edge. STL is hands down the worst collections framework I've ever encountered. Consider just a few examples of how you do some common operations with it, compared to doing the same things in Java and Python.

    1. Check whether a string s ends with a suffix t.

    Java: s.endsWith(t)
    Python: s.endswith(t)
    C++: s.rfind(t) == s.size()-t.size()

    2. Check whether a collection c contains an element e.

    Java: c.contains(e)
    Python: e in c
    C++: c.find(e) != c.end()

    3. Split a string s into tokens based on whitespace.

    Java: s.split()
    Python: s.split()
    C++: ... do you really want to know? Ok, check out http://stackoverflow.com/quest... [stackoverflow.com]. There you will find dozens of proposed solutions (many of them quite indecipherable), along with lots of debate about which one is best. The top voted solution has a comment on it (with several hundred votes) saying that it's a bad solution and you shouldn't use it.

    Doing even really basic, common operations with STL requires way too much work and produces absurd, hard to read code.

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Working...