Pretty much only use-after-free and double-free of that list is truly solved by unique_ptr, which is great, but nothing like what you say:
- std::move out of a unique_ptr x and "*x" is a null pointer dereference,
- take a reference into a unique_ptr, and it becomes dangling if it is held after the pointer is deallocated,
- an T[N] array doesn't get bounds-checked whether or not it is stored in a std::unique_ptr (it is nice that it reduces the number of raw pointers flying around, which likely does reduce the number of out-of-bounds accesses, but it doesn't solve them)
Clang does a good number of warnings/errors on unique_ptr, and I'm not sure your first point is actually right - it tends to be pretty hard to use after move.
If you want to pay the cost of runtime array checking every time, an impl in operator[] is just a few lines long. Thankfully it is becoming more common to run programs under ASAN in dev mode.
It is trivial to use-after-move. The following compiles completely without warnings with the clang on my system (even with -Wall -Weverything), and segfaults:
#include <memory>
int main() {
std::unique_ptr<int> p = std::make_unique<int>(0);
std::unique_ptr<int> q(std::move(p));
return *p;
}
Maybe you mean it doesn't happen much in practice, which might be true (although, we need to be comparing use-after-move with use-after-free etc., which also don't happen that much, per line-of-code), but is a different point. The fact remains that unique_ptr doesn't solve use-after-move.
> If you want to pay the cost of runtime array checking every time, an impl in operator[] is just a few lines long
This is also a different point, and moving the goal posts.
In any case, which operator[] exactly? AFAIK, neither T[N] nor T* can have a custom operator[] (and getting the bounds of a raw pointer is essentially impossible), and none of the operator[]s of std::array nor std::vector nor std::span do bounds checking (sure, you can use ...::at for the first two, but you have to remember to do that everywhere, going against the default that pretty much every programming language uses).
> Thankfully it is becoming more common to run programs under ASAN in dev mode.
Yes, this is great! However, this is yet another different point, and it is orthogonal to modern C++ and its fancy new features like std::unique_ptr: C++98 code, and even C code benefit from ASan.
