[daeken]

I must say, I made a beeline for the security page and was not disappointed. While I think they underplay the risk of memory corruption flaws (namely by emphasizing backups to be critical, rather than isolating user data to minimize compromise in the case of the site being owned), they otherwise do a fantastic job. I can nitpick a bit (and will probably send some recommendations to improve the guide a little) but I really have to commend them on that.

[pcwalton]

I knew I would find a statement like this in the security page: "So using modern language techniques programming in C++ is not more dangerous then programming in Java, Python or Ruby."

This is a belief that many C++ programmers have, and having spent much of my life in the past few years finding ways to break a C++-like memory model (Rust) I cannot emphasize enough how dangerously wrong it is. Safer than C, sure. As safe as a memory-safe language like Java, absolutely not.

[dakimov]

What are you talking about?

The safety you mentioned comes from only two things: type safety and runtime array boundary checks.

There is no problem in implementing runtime boundary check in C++.

What else in C++ is less safe than in Java? Is there some kind of magic?

[pcwalton]

Iterator invalidation, returning references that outlive their referent, storing references in data structures that outlive their referent, invalidation of the "this" pointer, etc.

[dakimov]

Basically those are examples of bare pointer manipulations (as references are essentially syntactically sugared bare pointers).

Although it can be mitigated with specially written collections (incompatible with the standard collections) and strict coding guidelines, I have to agree with you that the C++ memory model itself is insanely dangerous.