The rest of us isn't that big number according to Microsoft and Google security reports.

I surely have my share of C++ pointer mistakes done since I got hold of C++ARM and Turbo C++, after years of Assembly and Turbo Pascal programming.

Not only C++, but any other language with manual memory management, because keeping track of where everything is going manually, just doesn't scale.

I think the evidence is pretty clear that programmers can't, in general, use bare pointers properly. The very best write use after free, double free, stack smashers, and all manner of other memory related bugs. We can see the evidence of this fact in the CVEs, the syzkaller bugs, etc. If you haven't been bitten by a serious instance of one of these, then you just haven't written very much C++.

IMO the debate about whether programmers can safely handle bare pointers is over. They can't. The only question is whether smart pointers help enough to make the extra line noise worth it.

And the guys that implement smart pointers are what, exactly? Uberprogrammers? Is there a certificate to get into that club? What about compiler authors, that deal with, gasp, optimizations of these bare pointers? Kernel developers? Embedded system engineers?

It is ok to stay above a certain level of abstractions consciously, but stating that one cannot go below safely is just steadying mediocrity.

> And the guys that implement smart pointers are what, exactly? Uberprogrammers? Is there a certificate to get into that club? What about compiler authors, that deal with, gasp, optimizations of these bare pointers? Kernel developers? Embedded system engineers?

One cannot do any of those things safely by hand. Compilers, kernels, and embedded systems do indeed do these things; they also have bugs.

You are contradicting yourself. If one cannot do these things safely by hand, then noone can implement the automatic abstractions either.

You cannot safely control an internal combustion engine's valve timings by hand, but it is clearly possible to implement this automatically (and fairly simply). Some things are much easier for machines to do than humans, even though the machines are designed and build by humans.

> Is there a certificate to get into that club?

There is and the large majority fails at it, as proven by the CVE database, in spite the rigorous process to contribute code to the Linux kernel for example.

I call bullshit. And arrogant bullshit at that. The wast majority of bare metal components is highly functional and relatively bug free.

You can call whatever you like, CVE database, yearly security reports, and OS release notes from all major OSes provide the necessary facts.

Sadly liability still isn't a thing on software development.

That's not the point. Smart pointer implementations aren't some dark magic, they're just the opposite: mostly fairly simple to implement (shared_ptr is a little trickier), and obviously right by construction: the compiler does the hard work of making sure the constructors and destructors get called appropriately (and this is a little harder but still far far easier than making sure that malloc() and free() match in all actual uses).

> just because you don't like pointers, does not mean the rest of us can't use them perfectly safely.

I actually use pointers quite safely. I just no longer see a need to ever return an allocation from `new` to a raw pointer unless I'm implementing my own pointer class.

Herb Sutter's correct [0]. `std::unique_ptr` or `std::shared_ptr` or some other pointer container should __always__ hold new-allocated objects. Just like you should __always__ wear your seatbelt. It's no danger to you or anyone else, it's slightly inconvenient, and it saves a metric ton of headaches about "what if?". Because in reality a pointer container explicitly marks the scope of the allocation and if you're not wanting to use C++'s scoping rules then why are you using C++?

[0] https://www.youtube.com/watch?v=JfmTagWcqoE

The statement you quoted is simply a fact, not badmouthing. If there is any badmouthing by implication, it wouldn't be "all" C++ developers, just those who don't realize they're doing something spooky when their code looks like Foo *foo = new Foo.