3 ms·

This article is from 1997, you should at least mention this in the title.

• cousin_it 14y ago
  Which of the listed pitfalls are gone in C++11?
  • jeremiep 14y ago
    Probably none, I see programmers falling for these every week at work, it's 2012 now. The C++11 revision didn't change much other than add to the already joyful cursing because now compiler support is even more of an issue than it ever was.
    • lbrandy 14y ago
      There's a few where C++11 has rendered the situation far less common, or the advice not-so-good. For example, the auto_ptr one (advice should be: don't use it). Or the ones that use raw pointer data members and 'delete' in the destructor (for example, the one about the rule of three). This is still good advice, but needed far, far, far more rarely since we can use shared_ptr and unique_ptr to give proper copy/assignment to internal pointers. C++11 has gotten us to a point where using 'new' or 'delete' keywords, even in constructor/destructors are possible code smells.
  • deleted 14y ago
    [deleted]
  • pdw 14y ago
    The second is avoided if you use C++11-style initializers: string a{"Hello"}; string b{}; string c = string{"World"}; Many of the others also disappear if you stick to a "modern" style.
  • pandaman 14y ago
    Not with the C++11 by itself but with better compilers we've got since about 2000 (don't forget that the earliest C++ standard is from 1998): 1. Member initialization order being broken in the constructor initialization is a warning pretty much everywhere (except Microsoft compilers, I think). 2. Having a virtual function and no virtual destructor - a warning even in Microsoft compilers. 3. Trivial infinite recursion (i.e. Manager::print() { print(); } is a warning at least in some compilers. I have seen only a handful of projects where such code existed at all so I cannot say how widespread this warning (For me it popped due to problems with scripts generating code, people don't write this stuff ). This is just from glancing over the article, I am sure if you tried all pitfalls with a modern compiler like clang or even gcc, you'd get a few more warnings. Though I agree with the main point the author is trying to make - C++ is not just Java with pointers so if you are coming from Java background you should be very careful not to assume the conventions you've got used in Java are the same in C++.
    • UnFleshedOne 14y ago
      I never understood the need for blanket warnings for member initialization order on gcc. 99% of the time the order doesn't matter (who cares if I assign zero to one int or another first). And when it does, it is better to move initialization to the body of constructor anyway. Basically I have to do annoying reordering every time I do some changes on msvc and then compile on gcc just to remove the warnings.
  • baobab 14y ago
    With explicit conversion operators you can fix this: "if (-0.5 <= x <= 0.5) return 0;" for x that are not built-in types. You would need to create your own Bool type, something like defined below, and overload <= operators for x type, returning Bool. This way you will get compile time error. class Bool { bool value; public: Bool(bool v) : value(v) {} explicit operator bool () { return value; } };