A std::unique_ptr is no safer than a value on the stack, which is unsafe in C++. It only introduces the additional problems of having null pointer dereferences and encouraging use-after-move. The fundamental problem is that it frees when there are still active references.
Conversation
Having that free as automatic / implicit certainly makes it harder to leak memory, but in the real world I don't think it improves safety. Many of the memory corruption bugs that I find are due to use-after-free largely missed due to implicit C++ destruction at the end of scope.
1
The most common bugs that I run into are issues like std::string going out of scope and an active reference still being used. en.cppreference.com/w/cpp/string/b is going to make that worse by offering an important performance feature used extensively in Rust, but it's totally unsafe in C++.
1
Can you please explain how would you have references to uniq_ptr if you keep the idiom of never using get()?
Yes, iterators are evil b/c use after free. With string or vector.
This is not the case in uniq_ptr.
(Tree structure is immensely useful.)
1
vector<unique_ptr<Foo>> v;
v.push_back(std::make_unique(Foo()));
Foo& foo = v[0];
v.clear();
foo.bar(); // UB
2
2
Um, yeah. You leaked reference to the vector. You could've put anything in the vector. uniq_ptr is just a red herring here
That's my point, 's point about references (=raw ptr) are evil is great. Not relevant to uniq_ptr w/o get(), which is the common use case AFAIK
1
All I'm saying is std::unique_ptr does nothing to help. It's slightly less safe to have `std::unique_ptr<T> foo` than `T foo` since it can be null and encourages moving, but other than that it makes little difference. It's best avoided unless you really need lighter moves/swaps.
1
How would you do __attribute__((cleanup)) without uniq_ptr.
Except it's excellent for documenting ownership.
And lighter move/swap are really useful. As I said, pimpl.
1
No need to document something that's already standard for any value type. Should be using proper types for resources like a proper file type rather than defining ad-hoc dynamic versions using std::unique_ptr. Open coding these low-level things is a bad idea in general.
1
I rarely find any use case for std::unique_ptr<T> or Box<T> in Rust unless I need a custom tree data structure. Part of the reason for that is because I avoid dynamic dispatch and prefer concrete types, *especially* in C++ where dynamic dispatch is via class-based inheritance.
1
I consider class-based inheritance to be an incredibly awful idea in most cases. One of the only times it's actually a good idea instead of interfaces is when being forced to implement an external class-based inheritance scheme because the standard you're implementing uses it.