Higher level constructs like iterators, references and smart pointers are all relatively easy to misuse. It is definitely possible to have safe abstractions like std::string's + and they're one reason why C++ is an improvement over C, but there's still many other dangerous edges that are nearly impossible for a human to keep track of at scale.

There are things in the C++ standard library that are not very well designed, yes.

For instance, erasing from some containers causes undefined behavior if iterators that were created before the deletion continue to be used.

Some of the various smart pointers for managing memory are not so smart; they have been redesigning new ones and deprecating old ones so many times now. It used to be "your code isn't exception safe: use auto_ptr, you dolt!". Then, "you idiot, don't use auto_ptr, use this instead" and so on.

You can avoid all that by defining your own classes that do just what you need, use only the safe stuff from the standard (like the aforementioned strings) and write yourself a perfectly memory-safe, leak-free C++ program.

Even the modernest pointers unique_ptr and shared_ptr are dangerous (use after free/move and, e.g., ease of data-racing in the data, respectively). The problems with them are relatively fundamental to C++ and its idioms. The classes you define will need to avoid using fundamental C++ features like references too: anything pointer-like can lead to problems (including `this`)

The "you (and the standard library, including the completely new parts) are holding it wrong" defence is tired, when it is so ridiculously easy to do so: it is okay and important to acknowledge that a tool is powerful but also has a pile of hard-to-avoid sharp edges.

I fully agree, but you cannot oblige everyone that touches the code to have the same care, and so the typical "C with C++ compiler" idioms sneak in, thus decreasing overall safety.

This is specially the case in the majority of enterprise software that doesn't use any kind of static validation tooling, or CI builds.

> you cannot oblige everyone that touches the code to have the same care

If you can't enforce that certain rules be enforced in a C++ program, you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language.

> doesn't use any kind of static validation tooling, or CI build

Or, also: a review tool for rejecting stuff that is against the project's explicit coding guidelines.

> you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language.

In Java and .NET projects you can easily ensure that, and that is a common scenario in some of our customers.

The machines are provided locked down by IT with the project sanctioned tools, including the configuration for in-house Maven and NuGET repositories.

No native code compiler gets installed, servers are configured to disallow unsafe code.

Any library not available requires a change request to the IT team.

With that environment and people, we could easily enforce C++ rules in the same way.

Stuff you don't want in C++ code can be rejected by a pre-commit hook which scans code. That header can't be #include-ed, that crazy operator can't be used, etc.

Also, with open source compilers, you can implement your own warnings. (Been there, done that; in the role of an embedded distro/kernel/toolchain person some years ago, I hacked g++ with custom warnings).

If there is something we don't want in C++, and it doesn't "grep" well, we may be able to diagnose its presence in the compiler and treat that as an error.

Not really, the part you are missing is that it is easier and cheaper not to have C or C++ compilers available at all.

No, what I mean that if those same people were running a C++ shop rather than a Java shop, they could be equally and just as effectively draconian in their enforcement.

Ah I get your point, but static analysers and sanitizers aren't able to find all unsafe issues, specially if binary dependencies are involved.

This is why on Solaris there is OS support via SPARC instructions to enforce bounds and valid pointer use, for example.

That's actually why I call BS on anyone who says "C/C++" while claiming to be a (former) C++ high level user (dabbling in it doesn't count, I dabbled Java, C# and PHP but it's not even on my CV because I don't consider myself anywhere near production level in them) and try to use "C and C++" myself. See: http://www.stroustrup.com/bs_faq.html#C-slash