6 ms·

Defective C++

14 points by dsplatonov 12y ago

loup-vaillant 12y ago
This page is about C++98. C++11 and 14, while making some important things easier, have their own set of problems. Which is why Yossi Kreinin called for help about updating the FQA for C++1x and beyond. As he no longer works with C++, both his expertise and the time he can waste on this language are dwindling. http://yosefk.com/blog/c11-fqa-anyone.html http://yosefk.com/blog/c11-fqa-anyone.html
- fetbaffe 12y ago
  A good FQA and a great blog post summary. And you can see the same shrewdness, the same "altruism", the same attention to detail, the same tunnel vision – "this shit I'm working on is so important, it deserves all of my mental energy AND the mental energy of my users at the expense of caring about anything else" – throughout the C++ culture. From the boost libraries to "Modern C++ Design" (the author has since repented and moved to D – or did he repent?..) to the justifications for duplicate and triplicate and still incomplete language features to your local C++ expert carrying his crazy libraries and syntactic wrappers and tangling your entire code base in his net. So true. In the beginning of my career, I too was drinking the C++ koolaid. I really believed that manual memory management, large and convoluted class hierarchies, obscure template programming, cryptic exception handling, and pointer tinkering was necessary in a language and, of course, to get good performance you had to use C++. What a complete lie. I still meet programmers who believe that, because it is important. And then you look at what kind of software they are writing, some desktop app or some web service. Huh. If you look where the C++ community ended up by C++ programming experience over the years is that you should probably avoid all of that if you want bug free code.
  - nly 12y ago
    > I really believed that manual memory management, large and convoluted class hierarchies, obscure template programming, cryptic exception handling, and pointer tinkering was necessary in a language and, of course, to get good performance you had to use C++. What a complete lie. It was a complete lie. Fortunately, none of that stuff precludes you from using C++.
    - fetbaffe 12y ago
      True, and when I need to use C++ today I use a small subset of it with some new features from C++11. Namespaces, functions, structs, lambdas and smart pointers is usually all I need. The standard library has become so much better then the old days. Now I can even create threads without extra libraries. Unfortunately std types are no longer COW with C++11. Now if I only can get rid of that awful header file I almost have something that works without too much headache and profanity.
      - nly 12y ago
        > Unfortunately std types are no longer COW with C++11. GNU std::string being CoW (still is atm btw) has always been deceitful. The API was simply never designed for that implementation, which resulted in seemingly cheap read-only operations (char x = str[42];) becoming quite expensive. I'm glad you mentioned actually, since API authors embracing reference semantics through fear of overhead is a great rabbit hole of systemic complexity for C++ developers who are then forced to swim against the tide in the language. Sadly I don't think Rust goes far enough in bringing love to value semantics.
        fetbaffe 12y ago
        Ah, I did not know that. I mostly use CoW when I do Qt stuff to get a clean API (but Qt gives you whole range of other annoyances). Qt data types works well together with std lambdas without the need of smart pointers. In what other language has so many Stack Overflow threads and blog post been dedicated just how to pass a simple parameter to a function. And with C++11 we have one more way of doing it. It is really mind-boggling. I never have this problem in other languages and I can do equal the heavy lifting. And for the C++ programmer it gives a false sense of satisfaction when spraying the code with const& everywhere. I saved performance! Just bizarre.
shin_lao 12y ago
This FQA is often posted and you should know it's subjective and outdated. You can read more about it here: http://stackoverflow.com/questions/3171647/errors-in-c-fqa http://stackoverflow.com/questions/3171647/errors-in-c-fqa
- loup-vaillant 12y ago
  And there: http://www.yosefk.com/c++fqa/web-vs-fqa.html http://www.yosefk.com/c++fqa/web-vs-fqa.html As for the "subjective" part, it doesn't really weaken the argument of the FQA. I estimate most of his "subjective" claims are subjectively true for most programmers. When something is subjectively true for a sufficiently large majority of the relevant group of sentient beings, asserting its truth, period, is common usage.
  - shin_lao 12y ago
    The FQA states that the C++ doesn't have garbage collection and presents that as a problem. It's a non sequitur. It's like saying "I don't like this knife, I cannot eat soup with it".
    - loup-vaillant 12y ago
      I agree with your non sequitur, but I think there is something there nonetheless. I think Yossi Kreinin's main objection is not the absence of garbage collection in C++, but the fact that so many projects that could use garbage collection, don't. Like "I need performance!" No you don't. "I really need performance!" My GC is just as fast as your malloc/free. "I don't use malloc/free, I have my own custom allocators, you ignorant Java programmer!" I just use manually managed arrays for that, and enjoy garbage collection for the rest of my data. "My environment can't afford me any GC pause!" My GC hardly pause, and it collects gigabytes of data. "But I know things about my data your GC don't!" OK, now you may have a point. The performance difference between C++ and a well implemented native language with garbage collection (OCaml, Haskell, Lisp, Go…) is not large. Definitely less than an order of magnitude. Your constraints must be real tight to force you to give up garbage collection. In the vast majority of projects, not using garbage collection is a problem. If not with the language, at least with the community. --- I think Yossi Kreinin don't object the knife itself. He objects the fact that people actually try to eat soup with that damn knife, spilling soup and cutting their tongue in the process. Sometimes, we do need sharp edges (for cutting meat). But for much eating activities, sharp edges are just a hindrance.
Pacabel 12y ago
It's pretty well known that C++ suffers from a variety of problems. Many of them have been known about for some time. Despite this, nobody has been able to produce a truly viable alternative. There have been some encouraging developments, of course. But they've had their own drawbacks that are often worse, in practice, than the problems of C++. D is an example of this. A lot of new and existing C++ code probably could be written in D instead. But D lacks the widespread adoption and support that C++ offers. This translates into there being fewer third party libraries available, which increases the burden on programmers to an extent that's usually unjustifiable during commercial development And this, in turn, helps prevent the adoption of D. Rust is another example. It theoretically sounds like it could be a replacement for C++, but that's only true in the far future. The language and its standard libraries have yet to show any real signs of stability. We've been hearing that there may be a 1.0 release at the end of 2014, but time is quickly running out on this. Even then, it will merely be where D is at that point. While there may be a fair number of Rust libraries in existence at this point, many of them have become broken due to language or standard library changes, many are woefully incomplete, and many are totally abandoned. Then there are Java, C#, Go and others which claim to be successors or potential replacements, and perhaps this is true in a very limited subset of cases. But the remaining situations where they aren't suitable are large in number and quite critical. Furthermore, we are continually seeing C++ adapt and evolve. It's getting new features and functionality that these competitors are offering, while still usually giving far more freedom and control to programmers, far better performance, far better portability, far greater practicality, and continued use for serious new software projects. These factors combine to make it an even more difficult situation for potential C++ replacements. They just may not bring enough to the table to warrant replacing C++ for a majority of its users or potential users.
- pkolaczk 12y ago
  "Then there are Java, C#, Go and others which claim to be successors or potential replacements, and perhaps this is true in a very limited subset of cases." If this sentence was true, we'd see only a small adoption of Java and C#, and huge adoption of C++. But I'm afraid you're wrong, and this is exactly reversed now. There's huge adoption of Java/C# used in critical systems in many big companies, while a few niches like embedded programming, games or HFT still use C++ (not exclusively). This is very, very far from "large in number and critical". "Furthermore, we are continually seeing C++ adapt and evolve." Indeed. This C++ job trend illustrates this "growing adoption" very clearly: http://www.indeed.com/jobtrends?q=C%2B%2B&l= http://www.indeed.com/jobtrends?q=C%2B%2B&l=
silmar 12y ago
While c++ has its share of annoyances, I fail to see the relevance of this text, even more so in 2014, why do You repost it?
- loup-vaillant 12y ago
  C++14 has a good share of the problems of C++98, while adding its own. It's not like C++ ceased to be the most crazily complex and the most deadly trapped language in widespread use. I'll grant the FQA as such is outdated, but irrelevant? C++ was a huge mistake to begin with, a giant waste of time at the global scale. (Things are different at the individual scale, because network effects.) Having a heavily documented case for the oblivion of C++ is a good thing.

14 points by dsplatonov 12y ago

This page is about C++98. C++11 and 14, while making some important things easier, have their own set of problems. Which is why Yossi Kreinin called for help about updating the FQA for C++1x and beyond. As he no longer works with C++, both his expertise and the time he can waste on this language are dwindling. http://yosefk.com/blog/c11-fqa-anyone.html http://yosefk.com/blog/c11-fqa-anyone.html

fetbaffe 12y ago
A good FQA and a great blog post summary. And you can see the same shrewdness, the same "altruism", the same attention to detail, the same tunnel vision – "this shit I'm working on is so important, it deserves all of my mental energy AND the mental energy of my users at the expense of caring about anything else" – throughout the C++ culture. From the boost libraries to "Modern C++ Design" (the author has since repented and moved to D – or did he repent?..) to the justifications for duplicate and triplicate and still incomplete language features to your local C++ expert carrying his crazy libraries and syntactic wrappers and tangling your entire code base in his net. So true. In the beginning of my career, I too was drinking the C++ koolaid. I really believed that manual memory management, large and convoluted class hierarchies, obscure template programming, cryptic exception handling, and pointer tinkering was necessary in a language and, of course, to get good performance you had to use C++. What a complete lie. I still meet programmers who believe that, because it is important. And then you look at what kind of software they are writing, some desktop app or some web service. Huh. If you look where the C++ community ended up by C++ programming experience over the years is that you should probably avoid all of that if you want bug free code.
- nly 12y ago
  > I really believed that manual memory management, large and convoluted class hierarchies, obscure template programming, cryptic exception handling, and pointer tinkering was necessary in a language and, of course, to get good performance you had to use C++. What a complete lie. It was a complete lie. Fortunately, none of that stuff precludes you from using C++.
  - fetbaffe 12y ago
    True, and when I need to use C++ today I use a small subset of it with some new features from C++11. Namespaces, functions, structs, lambdas and smart pointers is usually all I need. The standard library has become so much better then the old days. Now I can even create threads without extra libraries. Unfortunately std types are no longer COW with C++11. Now if I only can get rid of that awful header file I almost have something that works without too much headache and profanity.
    - nly 12y ago
      > Unfortunately std types are no longer COW with C++11. GNU std::string being CoW (still is atm btw) has always been deceitful. The API was simply never designed for that implementation, which resulted in seemingly cheap read-only operations (char x = str[42];) becoming quite expensive. I'm glad you mentioned actually, since API authors embracing reference semantics through fear of overhead is a great rabbit hole of systemic complexity for C++ developers who are then forced to swim against the tide in the language. Sadly I don't think Rust goes far enough in bringing love to value semantics.
      - fetbaffe 12y ago
        Ah, I did not know that. I mostly use CoW when I do Qt stuff to get a clean API (but Qt gives you whole range of other annoyances). Qt data types works well together with std lambdas without the need of smart pointers. In what other language has so many Stack Overflow threads and blog post been dedicated just how to pass a simple parameter to a function. And with C++11 we have one more way of doing it. It is really mind-boggling. I never have this problem in other languages and I can do equal the heavy lifting. And for the C++ programmer it gives a false sense of satisfaction when spraying the code with const& everywhere. I saved performance! Just bizarre.

shin_lao 12y ago

This FQA is often posted and you should know it's subjective and outdated. You can read more about it here: http://stackoverflow.com/questions/3171647/errors-in-c-fqa http://stackoverflow.com/questions/3171647/errors-in-c-fqa

loup-vaillant 12y ago
And there: http://www.yosefk.com/c++fqa/web-vs-fqa.html http://www.yosefk.com/c++fqa/web-vs-fqa.html As for the "subjective" part, it doesn't really weaken the argument of the FQA. I estimate most of his "subjective" claims are subjectively true for most programmers. When something is subjectively true for a sufficiently large majority of the relevant group of sentient beings, asserting its truth, period, is common usage.
- shin_lao 12y ago
  The FQA states that the C++ doesn't have garbage collection and presents that as a problem. It's a non sequitur. It's like saying "I don't like this knife, I cannot eat soup with it".
  - loup-vaillant 12y ago
    I agree with your non sequitur, but I think there is something there nonetheless. I think Yossi Kreinin's main objection is not the absence of garbage collection in C++, but the fact that so many projects that could use garbage collection, don't. Like "I need performance!" No you don't. "I really need performance!" My GC is just as fast as your malloc/free. "I don't use malloc/free, I have my own custom allocators, you ignorant Java programmer!" I just use manually managed arrays for that, and enjoy garbage collection for the rest of my data. "My environment can't afford me any GC pause!" My GC hardly pause, and it collects gigabytes of data. "But I know things about my data your GC don't!" OK, now you may have a point. The performance difference between C++ and a well implemented native language with garbage collection (OCaml, Haskell, Lisp, Go…) is not large. Definitely less than an order of magnitude. Your constraints must be real tight to force you to give up garbage collection. In the vast majority of projects, not using garbage collection is a problem. If not with the language, at least with the community. --- I think Yossi Kreinin don't object the knife itself. He objects the fact that people actually try to eat soup with that damn knife, spilling soup and cutting their tongue in the process. Sometimes, we do need sharp edges (for cutting meat). But for much eating activities, sharp edges are just a hindrance.

Pacabel 12y ago

It's pretty well known that C++ suffers from a variety of problems. Many of them have been known about for some time. Despite this, nobody has been able to produce a truly viable alternative. There have been some encouraging developments, of course. But they've had their own drawbacks that are often worse, in practice, than the problems of C++. D is an example of this. A lot of new and existing C++ code probably could be written in D instead. But D lacks the widespread adoption and support that C++ offers. This translates into there being fewer third party libraries available, which increases the burden on programmers to an extent that's usually unjustifiable during commercial development And this, in turn, helps prevent the adoption of D. Rust is another example. It theoretically sounds like it could be a replacement for C++, but that's only true in the far future. The language and its standard libraries have yet to show any real signs of stability. We've been hearing that there may be a 1.0 release at the end of 2014, but time is quickly running out on this. Even then, it will merely be where D is at that point. While there may be a fair number of Rust libraries in existence at this point, many of them have become broken due to language or standard library changes, many are woefully incomplete, and many are totally abandoned. Then there are Java, C#, Go and others which claim to be successors or potential replacements, and perhaps this is true in a very limited subset of cases. But the remaining situations where they aren't suitable are large in number and quite critical. Furthermore, we are continually seeing C++ adapt and evolve. It's getting new features and functionality that these competitors are offering, while still usually giving far more freedom and control to programmers, far better performance, far better portability, far greater practicality, and continued use for serious new software projects. These factors combine to make it an even more difficult situation for potential C++ replacements. They just may not bring enough to the table to warrant replacing C++ for a majority of its users or potential users.

pkolaczk 12y ago
"Then there are Java, C#, Go and others which claim to be successors or potential replacements, and perhaps this is true in a very limited subset of cases." If this sentence was true, we'd see only a small adoption of Java and C#, and huge adoption of C++. But I'm afraid you're wrong, and this is exactly reversed now. There's huge adoption of Java/C# used in critical systems in many big companies, while a few niches like embedded programming, games or HFT still use C++ (not exclusively). This is very, very far from "large in number and critical". "Furthermore, we are continually seeing C++ adapt and evolve." Indeed. This C++ job trend illustrates this "growing adoption" very clearly: http://www.indeed.com/jobtrends?q=C%2B%2B&l= http://www.indeed.com/jobtrends?q=C%2B%2B&l=

silmar 12y ago

While c++ has its share of annoyances, I fail to see the relevance of this text, even more so in 2014, why do You repost it?

loup-vaillant 12y ago
C++14 has a good share of the problems of C++98, while adding its own. It's not like C++ ceased to be the most crazily complex and the most deadly trapped language in widespread use. I'll grant the FQA as such is outdated, but irrelevant? C++ was a huge mistake to begin with, a giant waste of time at the global scale. (Things are different at the individual scale, because network effects.) Having a heavily documented case for the oblivion of C++ is a good thing.