The std::shared_ptr design also encourages data races, since it goes out of the way to provide thread safety with extremely inefficient atomic reference counting, but doesn't provide a locking mechanism paired with it.
Conversation
Weak pointers also make things even more unsafe for similar reasons as the baseline with unique pointers and shared pointers. Same applies to types like std::string. You have automatic free at end of scope, even after you've taken references / string views. Fundamental issue.
1
And yet, with no get(), and only using the uniq_ptr directly, you avoid a whole class of problem, and you still convey the ownership information to the reader.
You can still move ownership to other class.
I can't see how it happen when using raw ptr only at the uniq_ptr scope.
2
In fact I never ever used uniq_ptr::get() directly. I only used uptr->type.
(shared_ptr has its issues, but its still better than C ptr
generally speaking, rust gives a better scope compile time analysis, but C++ gives you some of that. It's not as good, but better than 0 of C)
1
C++ doesn't provide any compile-time safety from use-after-free, since references have no safety and are even implicit. Where are you even using std::unique_ptr? I don't find that there are many use cases for unique pointers other than implementing tree data structures.
1
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.
1
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
Generally std::unique_ptr isn't really the problem itself, it just doesn't do anything to help, and makes things slightly worse by introducing null pointer dereferences as an issue. Most modern C++ code doesn't need std::unique_ptr just like Box<T> is rarely used in Rust.