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:
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.
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++.
That is part what makes C++ worse: the fact that being a C++ experts primarily means knowing what not to do.