6 ms·

The Dark Side of C++ [pdf]

22 points by VeXocide 16y ago

fs111 16y ago
you should link to the original source: http://www.fefe.de/c++/ http://www.fefe.de/c++/
silentbicycle 16y ago
The article is called "The Dark SIDE of C++". (Must not get sucked into C++ bashing thread...)
- VeXocide 16y ago
  Fixed, thank you.
VBprogrammer 16y ago
I realise that if you pulled all the warts of any language together into on document it isn't going to make particularly nice reading. With C++ it is a bit like a horror story!
NewSoftzzz 16y ago
Most of the problems mentioned there don't apply to the regular C++ coder in his daily life, many of the mentioned problems are even non-existant if you stick to the encouraged coding styles of modern and real OOP C++. In practice just the template error messages suck as hell. I'd really like something nicer there, but in practice you actually survive those messages without too much wasting of time. You just ignore the error message and rather look at the line of code mentioned and then you usually find the problem rather fast by just looking at the line. rgds, René
- shin_lao 16y ago
  It's a compiler problem and clang is an attempt at solving it.
- colinb 16y ago
  "encouraged coding styles of modern and real OOP C++" Where do I go to learn those given that I work in an all C shop? One of the problems of learning C++ is the sheer profusion of material that's available, much of it written when the technology looked a lot shinier than it does now. Would you care to recommend some books or articles on C++ style that have stood the test of more than one fashion-epoch? I'm especially worried about the [to my eyes] rather large number of keywords in C++ and the many exciting ways in which they can interact. I think this is where advice about useful patterns [sorry] might be most useful. thanks c
  - alexk7 16y ago
    The book "C++ Coding Standards" by Herb Sutter and Andrei Alexandrescu is an excellent way to get up to date with modern yet pragmatic C++ style. I also recommend the "Effective C++" series by Scott Meyers and the "Exceptional C++" series by Herb Sutter.
  - NewSoftzzz 16y ago
    I really do recommend the C++ FAQ book. There is a lite version online: http://www.parashift.com/c++-faq-lite/ http://www.parashift.com/c++-faq-lite/ Since I've read both the lite online version and the book I strongly encourage you to obtain the book version! rgds, René
    - nuxi 16y ago
      In addition I'd recommend the C++ FQA lite (http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/) which dissects the FAQ and provides additional, a lot of times quite useful, information.
      - NewSoftzzz 16y ago
        The C++ FQA is quite the same stuff as the .pdf linked in this topic. So the same stuff about mostly not being practically relevant applies here. rgds, René
  - jerf 16y ago
huhtenberg 16y ago
The Dark Side of C++ is that everyone is an opinionated expert. C can be abused in a similar manner. The output of cpp is notoriously hard to read, especially if all newlines are removed :) But this is implied and understood by your average C programmer and therefore it is simply not worth discussing.
shin_lao 16y ago
The "hard to read part" is not very honest. You can so similar slides for a awful lot of languages, I'm not sure I see the point. C macros, for one, introduce similar issues. The "C++ makes auditing painful" is just flat out wrong. Any decent IDE alleviates the trivial ambiguities given as an example (references...). Auditing isn't done in just reading the code when reaching a certain size, anyway, so I'm not sure where the author wants to go. Additionally, a properly written program is consistent, and that's true for any language. If the program you audit is inconsistent, I can feel your pain, but don't blame C++ for it. I also don't understand what "too powerful" means. Power is relative, that C++ is too powerful for many tasks is an obvious statement but saying that it's just "too powerful full stop" is a bit silly, isn't it?
megafotze 16y ago
the author of this paper looks like this: http://htlr.org/lad35fh http://htlr.org/lad35fh (yes, it's him)
geophile 16y ago
The author points out that auto_ptr is useless. shared_ptr is broken too. What do you think this program does? #include <stdlib.h> #include <tr1/memory> #include <iostream> using namespace std; using namespace std::tr1; class Node; typedef shared_ptr<Node> NodePtr; class Node { public: int data; NodePtr next; Node(int data, NodePtr next) : data(data), next(next) {} ~Node(); }; Node::~Node() { /* cout << "Destroying " << data << endl; */ } void shared_ptr_vs_linked_list(int n) { NodePtr head; for (int i = 0; i < n; i++) { head.reset(new Node(i, head)); } head.reset(); cout << "Done " << n << endl; } int main(int argc, const char** argv) { shared_ptr_vs_linked_list(atoi(argv[1])); exit(0); }
- kinghajj 16y ago
  I don't see the problem. The nodes of the list are freed from beginning to end, and then "Done" is printed. What's supposed to be wrong here?
  - geophile 16y ago
    Stack overflow for large n.
    - kinghajj 16y ago
      Ah, I didn't consider that. A decent optimizing compiler should be able to remove all the tail calls (G++ did this with your code and -O2), so this shouldn't be a problem in practice, except maybe for debugging.
elmindreda 16y ago
He makes a valid point; i.e. if you write bad code, your code will be bad.
ramy_d 16y ago
it's hard to take an article like this seriously - i just want to make 2 highlights. he started using C++ when the STL didn't exist yet. This is ancient IMO, so his section on ever-changing standard is moot to me. if he didn't want to maintain the code base, then he should have kept using an older compiler. second highlight, errors messages - Debugging is the first skill programmers (re)learn, so IMO it's a pretty important one. when he says "You get an error message? You start fudging the code until it compiles." is down right negligent at best - C++ will tell you at exactly in which file, at which line and in which function called from which class your error was caused (more than i can say for other languages) and, i'm sorry, but if you don't know that compiler errors wrap the code in ' ' then wtf have you been doing since the dinosaur age when C++ had no stl? yes, the STL makes compiler errors extra long but to say you need to fudge with your code to make it work is a spray of FUD to anyone looking to get into the language. To close this, everything he said in his "hard to read" could be applied to any languages with mutability. The code snippets he took were so small or narrow that no one could be expected to make anything of it. C++ is a strong typed language, should be read as such and evaluated as such.
- silentbicycle 16y ago
  > To close this, everything he said in his "hard to read" could be applied to any languages with mutability. Really? I dare you to make Python code as hard to read. It has mutability, too. Hell, does C code have that same amount of overloading? The worst things C offers are function pointers and preprocessor hijinks* , while C++ proudly adds whole new categories of ways to make code hard to parse or reason about. (To say nothing of compile times.) I learned C++ before the STL, too. For what the STL accomplishes, I'd rather just use OCaml. C + Lua is also nice - the division emphasizes their strong points, and each seems to keep each others' complexities in check. * http://www.reddit.com/r/programming/comments/b507c/ask_reddit_to_counter_todays_negativity_whats_the/c0l1hxh http://www.reddit.com/r/programming/comments/b507c/ask_reddi...
  - shin_lao 16y ago
    C has got macros, so it can be very hard to read too. Generators (http://docs.python.org/tutorial/classes.html#generators http://docs.python.org/tutorial/classes.html#generators) in Python can make code very hard to read as well in "hiding" a lot of complexity inside the generation. In other words, such code: r = f(param) can be a lot of different things as well. The enter/exit clauses hide a lot of code as well, although they should be used for (de)initialization they can be abused (I've seen it). Finally, I think you should elaborate more when you say "for what the STL accomplishes, I'd rather just use OCaml" because I don't understand what it means and I know both languages (C++ much better, admittedly).
Silhouette 16y ago
Please can we stop promoting these language-bashing articles? Proposing an idea for a new language that avoids a flaw in existing languages might be interesting. Actual implementation of such an idea in a working compiler/interpreter that we can play with might be very interesting. Just reiterating a bunch of potential dangers in an old language is not interesting, and it's never going to be. This goes double if the presentation is subjective and/or incorrect anyway.
loufoque 16y ago
"Shouldn't throw exceptions in constructors"? Seriously? It's actually strongly recommended to do so. Unlike what this article says, it works just fine: - if you throw from the constructor-initializer, it destructs all the members and the base classes that were already initialized, - if you throw from the constructor body, it destructs all local variables in scope then all members and base classes. As for not being able to call virtual functions from base classes, there are good reasons why it is not allowed. About bounds checking, GCC does provide a debug mode with operator[] doing bounds checking. Local static initialization is thread-safe (see the C++0x standard) Exception-safety is a serious issue, but solving this problem -- which is fairly easy, just use RAII -- actually leads to better and safer code.
dimatura 16y ago
Isn't the different behavior of at() versus operator[] in vectors intentional? So you use at() if you don't mind a small performance penalty for the sake of safety, and operator[] otherwise?
helmut_hed 16y ago
I like C++ but I think this article is helpful. Having come up the curve in the last few years, I notice a lot of things I stumbled on are listed... If this were titled "things to watch out for in C++" it could be a useful guide for people. Now, though, I just think "yes, that's right" for many of his points - but it won't stop me from using C++.
bad_alloc 16y ago
If you ever write code like template<class T> struct Loop { Loop<T*> operator->(); }; Loop<int> i, j = i->hooray; at work you are shown by the language that you have probably failed to think before you code. A plus in C++, rather than a downsinde. If you begin to realize that you need garbage collection you probably failed while choosing the appropriate language for your project or subproblem. Same thing here: struct a{typedef int foo;};struct a1:a{};struct a2:a{}; #define X(b,a) struct a##1:b##1,b##2{};struct a##2:b##1,b##2{}; X(a,b)X(b,c)X(c,d)X(d,e)X(e,f)X(f,g)X(g,h)X(h,i)X(i,j)X(j,k)X(k,l) X(l,m)X(m,n) n1::foo main(){} Wich sane person would consider writing this a good idea?

22 points by VeXocide 16y ago

fs111 16y ago

you should link to the original source: http://www.fefe.de/c++/ http://www.fefe.de/c++/

silentbicycle 16y ago

The article is called "The Dark SIDE of C++". (Must not get sucked into C++ bashing thread...)

VeXocide 16y ago
Fixed, thank you.

VBprogrammer 16y ago

I realise that if you pulled all the warts of any language together into on document it isn't going to make particularly nice reading. With C++ it is a bit like a horror story!

NewSoftzzz 16y ago

Most of the problems mentioned there don't apply to the regular C++ coder in his daily life, many of the mentioned problems are even non-existant if you stick to the encouraged coding styles of modern and real OOP C++. In practice just the template error messages suck as hell. I'd really like something nicer there, but in practice you actually survive those messages without too much wasting of time. You just ignore the error message and rather look at the line of code mentioned and then you usually find the problem rather fast by just looking at the line. rgds, René

shin_lao 16y ago
It's a compiler problem and clang is an attempt at solving it.
colinb 16y ago
"encouraged coding styles of modern and real OOP C++" Where do I go to learn those given that I work in an all C shop? One of the problems of learning C++ is the sheer profusion of material that's available, much of it written when the technology looked a lot shinier than it does now. Would you care to recommend some books or articles on C++ style that have stood the test of more than one fashion-epoch? I'm especially worried about the [to my eyes] rather large number of keywords in C++ and the many exciting ways in which they can interact. I think this is where advice about useful patterns [sorry] might be most useful. thanks c
- alexk7 16y ago
  The book "C++ Coding Standards" by Herb Sutter and Andrei Alexandrescu is an excellent way to get up to date with modern yet pragmatic C++ style. I also recommend the "Effective C++" series by Scott Meyers and the "Exceptional C++" series by Herb Sutter.
- NewSoftzzz 16y ago
  I really do recommend the C++ FAQ book. There is a lite version online: http://www.parashift.com/c++-faq-lite/ http://www.parashift.com/c++-faq-lite/ Since I've read both the lite online version and the book I strongly encourage you to obtain the book version! rgds, René
  - nuxi 16y ago
    In addition I'd recommend the C++ FQA lite (http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/) which dissects the FAQ and provides additional, a lot of times quite useful, information.
    - NewSoftzzz 16y ago
      The C++ FQA is quite the same stuff as the .pdf linked in this topic. So the same stuff about mostly not being practically relevant applies here. rgds, René
- jerf 16y ago

huhtenberg 16y ago

The Dark Side of C++ is that everyone is an opinionated expert. C can be abused in a similar manner. The output of cpp is notoriously hard to read, especially if all newlines are removed :) But this is implied and understood by your average C programmer and therefore it is simply not worth discussing.

shin_lao 16y ago

The "hard to read part" is not very honest. You can so similar slides for a awful lot of languages, I'm not sure I see the point. C macros, for one, introduce similar issues. The "C++ makes auditing painful" is just flat out wrong. Any decent IDE alleviates the trivial ambiguities given as an example (references...). Auditing isn't done in just reading the code when reaching a certain size, anyway, so I'm not sure where the author wants to go. Additionally, a properly written program is consistent, and that's true for any language. If the program you audit is inconsistent, I can feel your pain, but don't blame C++ for it. I also don't understand what "too powerful" means. Power is relative, that C++ is too powerful for many tasks is an obvious statement but saying that it's just "too powerful full stop" is a bit silly, isn't it?

megafotze 16y ago

the author of this paper looks like this: http://htlr.org/lad35fh http://htlr.org/lad35fh (yes, it's him)

geophile 16y ago

The author points out that auto_ptr is useless. shared_ptr is broken too. What do you think this program does? #include <stdlib.h> #include <tr1/memory> #include <iostream> using namespace std; using namespace std::tr1; class Node; typedef shared_ptr<Node> NodePtr; class Node { public: int data; NodePtr next; Node(int data, NodePtr next) : data(data), next(next) {} ~Node(); }; Node::~Node() { /* cout << "Destroying " << data << endl; */ } void shared_ptr_vs_linked_list(int n) { NodePtr head; for (int i = 0; i < n; i++) { head.reset(new Node(i, head)); } head.reset(); cout << "Done " << n << endl; } int main(int argc, const char** argv) { shared_ptr_vs_linked_list(atoi(argv[1])); exit(0); }

kinghajj 16y ago
I don't see the problem. The nodes of the list are freed from beginning to end, and then "Done" is printed. What's supposed to be wrong here?
- geophile 16y ago
  Stack overflow for large n.
  - kinghajj 16y ago
    Ah, I didn't consider that. A decent optimizing compiler should be able to remove all the tail calls (G++ did this with your code and -O2), so this shouldn't be a problem in practice, except maybe for debugging.

elmindreda 16y ago

He makes a valid point; i.e. if you write bad code, your code will be bad.

ramy_d 16y ago

it's hard to take an article like this seriously - i just want to make 2 highlights. he started using C++ when the STL didn't exist yet. This is ancient IMO, so his section on ever-changing standard is moot to me. if he didn't want to maintain the code base, then he should have kept using an older compiler. second highlight, errors messages - Debugging is the first skill programmers (re)learn, so IMO it's a pretty important one. when he says "You get an error message? You start fudging the code until it compiles." is down right negligent at best - C++ will tell you at exactly in which file, at which line and in which function called from which class your error was caused (more than i can say for other languages) and, i'm sorry, but if you don't know that compiler errors wrap the code in ' ' then wtf have you been doing since the dinosaur age when C++ had no stl? yes, the STL makes compiler errors extra long but to say you need to fudge with your code to make it work is a spray of FUD to anyone looking to get into the language. To close this, everything he said in his "hard to read" could be applied to any languages with mutability. The code snippets he took were so small or narrow that no one could be expected to make anything of it. C++ is a strong typed language, should be read as such and evaluated as such.

silentbicycle 16y ago
> To close this, everything he said in his "hard to read" could be applied to any languages with mutability. Really? I dare you to make Python code as hard to read. It has mutability, too. Hell, does C code have that same amount of overloading? The worst things C offers are function pointers and preprocessor hijinks* , while C++ proudly adds whole new categories of ways to make code hard to parse or reason about. (To say nothing of compile times.) I learned C++ before the STL, too. For what the STL accomplishes, I'd rather just use OCaml. C + Lua is also nice - the division emphasizes their strong points, and each seems to keep each others' complexities in check. * http://www.reddit.com/r/programming/comments/b507c/ask_reddit_to_counter_todays_negativity_whats_the/c0l1hxh http://www.reddit.com/r/programming/comments/b507c/ask_reddi...
- shin_lao 16y ago
  C has got macros, so it can be very hard to read too. Generators (http://docs.python.org/tutorial/classes.html#generators http://docs.python.org/tutorial/classes.html#generators) in Python can make code very hard to read as well in "hiding" a lot of complexity inside the generation. In other words, such code: r = f(param) can be a lot of different things as well. The enter/exit clauses hide a lot of code as well, although they should be used for (de)initialization they can be abused (I've seen it). Finally, I think you should elaborate more when you say "for what the STL accomplishes, I'd rather just use OCaml" because I don't understand what it means and I know both languages (C++ much better, admittedly).

Silhouette 16y ago

Please can we stop promoting these language-bashing articles? Proposing an idea for a new language that avoids a flaw in existing languages might be interesting. Actual implementation of such an idea in a working compiler/interpreter that we can play with might be very interesting. Just reiterating a bunch of potential dangers in an old language is not interesting, and it's never going to be. This goes double if the presentation is subjective and/or incorrect anyway.

loufoque 16y ago

"Shouldn't throw exceptions in constructors"? Seriously? It's actually strongly recommended to do so. Unlike what this article says, it works just fine: - if you throw from the constructor-initializer, it destructs all the members and the base classes that were already initialized, - if you throw from the constructor body, it destructs all local variables in scope then all members and base classes. As for not being able to call virtual functions from base classes, there are good reasons why it is not allowed. About bounds checking, GCC does provide a debug mode with operator[] doing bounds checking. Local static initialization is thread-safe (see the C++0x standard) Exception-safety is a serious issue, but solving this problem -- which is fairly easy, just use RAII -- actually leads to better and safer code.

dimatura 16y ago

Isn't the different behavior of at() versus operator[] in vectors intentional? So you use at() if you don't mind a small performance penalty for the sake of safety, and operator[] otherwise?

helmut_hed 16y ago

I like C++ but I think this article is helpful. Having come up the curve in the last few years, I notice a lot of things I stumbled on are listed... If this were titled "things to watch out for in C++" it could be a useful guide for people. Now, though, I just think "yes, that's right" for many of his points - but it won't stop me from using C++.

bad_alloc 16y ago

If you ever write code like template<class T> struct Loop { Loop<T*> operator->(); }; Loop<int> i, j = i->hooray; at work you are shown by the language that you have probably failed to think before you code. A plus in C++, rather than a downsinde. If you begin to realize that you need garbage collection you probably failed while choosing the appropriate language for your project or subproblem. Same thing here: struct a{typedef int foo;};struct a1:a{};struct a2:a{}; #define X(b,a) struct a##1:b##1,b##2{};struct a##2:b##1,b##2{}; X(a,b)X(b,c)X(c,d)X(d,e)X(e,f)X(f,g)X(g,h)X(h,i)X(i,j)X(j,k)X(k,l) X(l,m)X(m,n) n1::foo main(){} Wich sane person would consider writing this a good idea?