3 ms·

Stoustrup is right, there's many dark and really dank corners of C++ and people start poking around in them and bringing them into production code and that's ju

Stoustrup is right, there's many dark and really dank corners of C++ and people start poking around in them and bringing them into production code and that's just bad for everyone. It's like tigers, tigers are awesome and it's great that our ecosystem has developed to support them, but you don't put a tiger in your house. I do C++ dev work for a living, I enjoy it. The language can be a nightmare, but as long as you're sensible and frugal with what you're using it's no worse than anything else. The trick is to really, really think about whether a specific feature is worth taking into a more complex direction with some of the edgier C++ functionality, or sticking with more core, basic, understandable code which might trade off performance. I should probably say I've not done any 'proper' C++ development for a while, mostly we build with Qt and that abstracts a lot of the headaches away into a nice toolkit.

betterunix 14y ago
"as long as you're sensible and frugal with what you're using it's no worse than anything else" That is part what makes C++ worse: the fact that being a C++ experts primarily means knowing what not to do.
- JoeAltmaier 14y ago
  Oh come on; you have to try to find the dark corners, its not like they seek you out!
  - betterunix 14y ago
    Having taught C++ to novices, I can assure you that the "dark corners" are not hard to find. You need to be taught what is wrong in C++, and you need to learn "folklore" e.g. always use -Wall, before you can really program effectively in C++.
- nicholassmith 14y ago
  Being an expert in any language means knowing what not to do, more than knowing what you should do.
  - betterunix 14y ago
    Really? When someone says they are an expert in Java, they do not mean that they are well-versed in what sort of Java statements have unexpected, undefined, or indeterminate behavior. Even more so when someone calls themselves an expert in Lisp, Haskell, Scala, and other high-level languages. We are not talking about maintainability or style, we are talking about just being able to solve basic computational problems without having your program abort. In addition to this entire book on what not to do, books on advanced C++ programming (like the "Effective C++" series) are loaded with things you shouldn't do: http://www.semantics.org/cpp_gotchas/index.html http://www.semantics.org/cpp_gotchas/index.html C++ also encourages programmers to do "bad things," where other languages discourage such code. In Scheme, arguments to functions are evaluated in an undefined order, and so such arguments should never have global side effects; but Scheme discourages global side effects in general. In C++, arguments to functions are also evaluated in an undefined order...but global side effects are encouraged and widely used in C++, and it is easy to inadvertently create a situation where this becomes a problem (e.g. one argument might resize a vector, when the other is an iterator to that vector -- both common, both encouraged, but a pretty bad combination). C++ makes the most dangerous ways to do things the easiest and least verbose: pointers to access arrays, fixed-width integers, floating point numbers, etc.; other languages make such dangerous things more verbose and force programmers to be explicit when they try to utilize such constructs.

betterunix 14y ago

"as long as you're sensible and frugal with what you're using it's no worse than anything else" That is part what makes C++ worse: the fact that being a C++ experts primarily means knowing what not to do.

JoeAltmaier 14y ago
Oh come on; you have to try to find the dark corners, its not like they seek you out!
- betterunix 14y ago
  Having taught C++ to novices, I can assure you that the "dark corners" are not hard to find. You need to be taught what is wrong in C++, and you need to learn "folklore" e.g. always use -Wall, before you can really program effectively in C++.
nicholassmith 14y ago
Being an expert in any language means knowing what not to do, more than knowing what you should do.
- betterunix 14y ago
  Really? When someone says they are an expert in Java, they do not mean that they are well-versed in what sort of Java statements have unexpected, undefined, or indeterminate behavior. Even more so when someone calls themselves an expert in Lisp, Haskell, Scala, and other high-level languages. We are not talking about maintainability or style, we are talking about just being able to solve basic computational problems without having your program abort. In addition to this entire book on what not to do, books on advanced C++ programming (like the "Effective C++" series) are loaded with things you shouldn't do: http://www.semantics.org/cpp_gotchas/index.html http://www.semantics.org/cpp_gotchas/index.html C++ also encourages programmers to do "bad things," where other languages discourage such code. In Scheme, arguments to functions are evaluated in an undefined order, and so such arguments should never have global side effects; but Scheme discourages global side effects in general. In C++, arguments to functions are also evaluated in an undefined order...but global side effects are encouraged and widely used in C++, and it is easy to inadvertently create a situation where this becomes a problem (e.g. one argument might resize a vector, when the other is an iterator to that vector -- both common, both encouraged, but a pretty bad combination). C++ makes the most dangerous ways to do things the easiest and least verbose: pointers to access arrays, fixed-width integers, floating point numbers, etc.; other languages make such dangerous things more verbose and force programmers to be explicit when they try to utilize such constructs.