C++ pitfalls

It's missing my favorite, std::(unordered_)map::operator[]<p><pre><code> map&#60;int,int&#62; a; cout &#60;&#60; a[11] &#60;&#60; endl; cout &#60;&#60; a.size() &#60;&#60; endl; </code></pre> This works fine and has well defined behavior: it will print '0' followed by '1' since the middle line actually inserts a {key=11, value=0}.<p>This is a landmine I think every journeyman c++ programmer steps on a few times.

This is an interesting list to look through, but things are not as bad as they look.<p>Many of these are warned about on modern compilers, if you use '-Wextra -Wall'. Some of them are even on by default. I think compilers should warn more eagerly. I would put -Wextra -Wall on by default -- it is easier to turn off things you don't want, than to discover things you do not know exist. But I know this is not a popular opinion!

C++ provides high level stuff at the expense of making the programmer part of the compiler that must give it hints about memory, types or cope with multiple page error outputs because of one missing semicolon.<p>C++ exists because real high level languages does not have very efficient compilers yet.<p>And where high performance is really needed and programmers time or effort is not a problem C++ is preferred.<p>I expect that with the increasing processing power compilers will get some AI incorporated and get smarter in the future and high level languages will output binaries that are at least as fast as those produced by C++ or C compilers.

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

All languages have pitfalls. Including the author's beloved Java. For example:<p><pre><code> String x = "foo"; String y = "foo"; // Appears to work but compares references System.out.println(x[0] == x[1]); </code></pre> There's no substitute for knowing your tools well.

<p><pre><code> template&#60;typename T&#62; Array&#60;T&#62;::Array(int size) : _size(size), _data(new T(size)) // should have been new T[size] {} </code></pre> That's not the only thing wrong here.<p><pre><code> private: T* _data; int _size; }; </code></pre> The order of initialization is the order of declaration, NOT the order you use in your constructor.<p>_data depends on _size being initialized first. Therefore _size must be declared above _data.<p>Note: I understand the next example goes over this issue. I just think this example should've been declared properly as to avoid distracting the reader from the main problem, "() vs []".

This is 15 years old.

Do you go to SJSU? Hit me up! gregdmathews@gmail.com