4 ms·

Actually avoiding C++ pitfalls is not that difficult as most of them come from C: manual memory management, macros, varargs, unsafe casts. In fact C++ provides

by vitaut 11y ago

Actually avoiding C++ pitfalls is not that difficult as most of them come from C: manual memory management, macros, varargs, unsafe casts. In fact C++ provides safe alternatives to many of the unsafe C constructs, so if you stick to them you are fine.

nulltype 11y ago
The pitfalls of C++ that I've seen are mostly the things people build with the safe alternatives.
- vitaut 11y ago
  Could you give an example?
  - nulltype 11y ago
    I've seen some pretty impossible to comprehend or debug uses of templates. Perhaps my favorite, which represents most of the pitfalls you can create with C++ is the Boost library. And of that, the shining star is this page: http://www.boost.org/doc/libs/1_57_0/libs/geometry/doc/html/geometry/design.html http://www.boost.org/doc/libs/1_57_0/libs/geometry/doc/html/...
    - vitaut 11y ago
      I wouldn't call it a pitfall. Boost is written by C++ experts who like to push the boundaries of what can be done with the language. This doesn't mean that you have to debug their code or overuse templates yourself and there is nothing in the language that encourage this. For common cases such as in the standard library, templates are pretty easy to use and trivial to debug with modern compilers.
    - GFK_of_xmaspast 11y ago
      Given the design constraints: """ A generic library should be able to calculate the distance: for any point class or struct, not on just this mypoint type in more than two dimensions for other coordinate systems, e.g. over the earth or on a sphere between a point and a line or between other geometry combinations in higher precision than double avoiding the square root: often we don't want to do that because it is a relatively expensive function, and for comparing distances it is not necessary """ I suspect a little bit of complexity is necessary. (And can you even build something like this in a more fashionable language?)
deleted 11y ago
[deleted]
AlexandrB 11y ago
C++ not only fails to hide the above-mentioned C pitfalls but adds entire classes of pitfalls of its own. Just a few examples: * undecidable grammar: http://yosefk.com/c++fqa/defective.html#defect-2 http://yosefk.com/c++fqa/defective.html#defect-2 * const inside containers: http://yosefk.com/c++fqa/const.html#fqa-18.1 http://yosefk.com/c++fqa/const.html#fqa-18.1 * template error messages http://yosefk.com/c++fqa/templates.html#fqa-35.17 http://yosefk.com/c++fqa/templates.html#fqa-35.17 C is often nicer than C++ because it's simpler: it only has the C pitfalls not the combination of C & C++ pitfalls that plague C++.
- vitaut 11y ago
  These are trivial issues compared to major safety and usability flaws inherited from C that I mentioned. BTW the C grammar is not context-free either. The compilation speed is mostly due to header system which is again a C heritage, not because the C++ grammar is undecidable. And template error messages are much better now in modern compilers such as Clang. As for the const, its semantics is the same as in C.
  - the_why_of_y 11y ago
    The super-slow compilation speed is mostly because C++ encourages massive all-inline template libraries like the standard C++ library and boost, which need to be parsed and have the used templates instantiated for every compilation unit. Here's idiomatic hello world, with <iostream> vs. <stdio.h> > g++ -E hello.cc | wc -l 17906 > gcc -E hello.c | wc -l 842
jlarocco 11y ago
> Actually avoiding C++ pitfalls is not that difficult as most of them come from C If you really believe that, then you're probably writing dangerous code and not even realizing it. Most C++ pitfalls come from subtle interactions between features that don't even exist in C, like exceptions, move semantics, templates, threading, constructors/destructors, references, operator overloading, etc. Those are the things people are talking about when they mention the pitfalls of C++. The things you mention are the pitfalls of C, which technically still exist in C++, but they're not as interesting there because the C++ pitfalls are so subtle and dangerous.
- vitaut 11y ago
  I don't always write dangerous code, but when I do I fully realize it =). And it has nothing to do with any of the features that you listed. In fact "threading" in C++ is safer because of the availability of high-quality libraries providing task-based parallelism such as TBB, move semantics is used all the time in C albeit manually with pointer manipulation. It is true that not all of the features play well together, but it's nothing compared to the C pitfalls that I mentioned. If you want to avoid dangerous interactions, don't overengineer your code, stick to the features you understand. This is true not only for C++, but for any language.
  - jlarocco 11y ago
    > In fact "threading" in C++ is safer because of the availability of high-quality libraries providing task-based parallelism such as TBB, move semantics is used all the time in C albeit manually with pointer manipulation. It is true that not all of the features play well together, but it's nothing compared to the C pitfalls that I mentioned. Well, if I use libraries to avoid C's pitfalls, that language will be safe, too. > If you want to avoid dangerous interactions, don't overengineer your code, stick to the features you understand. This is true not only for C++, but for any language. That's almost useless advice. You might as well say the key to using C++ is to use Python or C instead. "Stick to the features you understand," doesn't even really work when coding by yourself. C++ is so incredibly complicated there's a very good chance most people wouldn't even really understand the limited subset they've stuck to. C++ devs with years of experience routinely mess up stuff like exactly when copy and move constructors are called. For example, how many copy constructors get called in this code: const std::string myString{"omg"}; std::cout << myString << (myString + myString); Most people will have to think about it for a little bit, and a lot of them will answer wrong. And that advice completely goes out the window when working with code written by other people. And it also means not using any C++ libraries because a lot of them use the full features of C++ and expect (or require) the code calling them use those features, too. The key to using C++ is to be aware there are many pitfalls, know when you're working with features that are particularly dangerous, have some resources that can help identify and avoid them (like the Effective C++ books), and whenever possible have other people review your code.

by vitaut 11y ago

nulltype 11y ago

The pitfalls of C++ that I've seen are mostly the things people build with the safe alternatives.

vitaut 11y ago
Could you give an example?
- nulltype 11y ago
  I've seen some pretty impossible to comprehend or debug uses of templates. Perhaps my favorite, which represents most of the pitfalls you can create with C++ is the Boost library. And of that, the shining star is this page: http://www.boost.org/doc/libs/1_57_0/libs/geometry/doc/html/geometry/design.html http://www.boost.org/doc/libs/1_57_0/libs/geometry/doc/html/...
  - vitaut 11y ago
    I wouldn't call it a pitfall. Boost is written by C++ experts who like to push the boundaries of what can be done with the language. This doesn't mean that you have to debug their code or overuse templates yourself and there is nothing in the language that encourage this. For common cases such as in the standard library, templates are pretty easy to use and trivial to debug with modern compilers.
  - GFK_of_xmaspast 11y ago
    Given the design constraints: """ A generic library should be able to calculate the distance: for any point class or struct, not on just this mypoint type in more than two dimensions for other coordinate systems, e.g. over the earth or on a sphere between a point and a line or between other geometry combinations in higher precision than double avoiding the square root: often we don't want to do that because it is a relatively expensive function, and for comparing distances it is not necessary """ I suspect a little bit of complexity is necessary. (And can you even build something like this in a more fashionable language?)

deleted 11y ago

[deleted]

AlexandrB 11y ago

C++ not only fails to hide the above-mentioned C pitfalls but adds entire classes of pitfalls of its own. Just a few examples: * undecidable grammar: http://yosefk.com/c++fqa/defective.html#defect-2 http://yosefk.com/c++fqa/defective.html#defect-2 * const inside containers: http://yosefk.com/c++fqa/const.html#fqa-18.1 http://yosefk.com/c++fqa/const.html#fqa-18.1 * template error messages http://yosefk.com/c++fqa/templates.html#fqa-35.17 http://yosefk.com/c++fqa/templates.html#fqa-35.17 C is often nicer than C++ because it's simpler: it only has the C pitfalls not the combination of C & C++ pitfalls that plague C++.

vitaut 11y ago
These are trivial issues compared to major safety and usability flaws inherited from C that I mentioned. BTW the C grammar is not context-free either. The compilation speed is mostly due to header system which is again a C heritage, not because the C++ grammar is undecidable. And template error messages are much better now in modern compilers such as Clang. As for the const, its semantics is the same as in C.
- the_why_of_y 11y ago
  The super-slow compilation speed is mostly because C++ encourages massive all-inline template libraries like the standard C++ library and boost, which need to be parsed and have the used templates instantiated for every compilation unit. Here's idiomatic hello world, with <iostream> vs. <stdio.h> > g++ -E hello.cc | wc -l 17906 > gcc -E hello.c | wc -l 842

jlarocco 11y ago

> Actually avoiding C++ pitfalls is not that difficult as most of them come from C If you really believe that, then you're probably writing dangerous code and not even realizing it. Most C++ pitfalls come from subtle interactions between features that don't even exist in C, like exceptions, move semantics, templates, threading, constructors/destructors, references, operator overloading, etc. Those are the things people are talking about when they mention the pitfalls of C++. The things you mention are the pitfalls of C, which technically still exist in C++, but they're not as interesting there because the C++ pitfalls are so subtle and dangerous.

vitaut 11y ago
I don't always write dangerous code, but when I do I fully realize it =). And it has nothing to do with any of the features that you listed. In fact "threading" in C++ is safer because of the availability of high-quality libraries providing task-based parallelism such as TBB, move semantics is used all the time in C albeit manually with pointer manipulation. It is true that not all of the features play well together, but it's nothing compared to the C pitfalls that I mentioned. If you want to avoid dangerous interactions, don't overengineer your code, stick to the features you understand. This is true not only for C++, but for any language.
- jlarocco 11y ago
  > In fact "threading" in C++ is safer because of the availability of high-quality libraries providing task-based parallelism such as TBB, move semantics is used all the time in C albeit manually with pointer manipulation. It is true that not all of the features play well together, but it's nothing compared to the C pitfalls that I mentioned. Well, if I use libraries to avoid C's pitfalls, that language will be safe, too. > If you want to avoid dangerous interactions, don't overengineer your code, stick to the features you understand. This is true not only for C++, but for any language. That's almost useless advice. You might as well say the key to using C++ is to use Python or C instead. "Stick to the features you understand," doesn't even really work when coding by yourself. C++ is so incredibly complicated there's a very good chance most people wouldn't even really understand the limited subset they've stuck to. C++ devs with years of experience routinely mess up stuff like exactly when copy and move constructors are called. For example, how many copy constructors get called in this code: const std::string myString{"omg"}; std::cout << myString << (myString + myString); Most people will have to think about it for a little bit, and a lot of them will answer wrong. And that advice completely goes out the window when working with code written by other people. And it also means not using any C++ libraries because a lot of them use the full features of C++ and expect (or require) the code calling them use those features, too. The key to using C++ is to be aware there are many pitfalls, know when you're working with features that are particularly dangerous, have some resources that can help identify and avoid them (like the Effective C++ books), and whenever possible have other people review your code.