Earlier quoted context omitted.
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 i…
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.
#include
int main() {
std::unique_ptr p = std::make_unique(0);
std::unique_ptr q(std::move(p));
return *p;
}
> 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.