I'm not saying that they're bad language features. It's awesome having pervasive use of lightweight references, iterators, string views, etc. but when you use something like iterators or en.cppreference.com/w/cpp/string/b in C++, it's an extreme danger. One tiny mistake is an RCE vuln.
Conversation
Iterators are evil, I perfectly agree. I don't see how can uniq_ptr cause those memory errors more than a raw pointer.
None of what you said can happen if you don't let the raw pointer escape, or am I missing something?
1
Yes, you're missing something. It clearly does absolutely nothing to prevent NULL dereferences or use-after-move so lets skip those. To use unique_ptr, you need to copy from it or get a reference. That reference isn't safe, and std::unique_ptr will still free with it active.
1
Why would you be using std::unique_ptr in the first place if you just want a value to copy around? That wouldn't make any sense. It's used to manage the lifetime of a dynamic allocation, where you are using it via references, not copying the contents out for every single use.
1
Similarly, for std::shared_ptr, you are still going to be using references to it, including mutable references, which are extremely dangerous in C++ since they can invalidate other references to the contents by changing the length of a container, a dynamic type, variant type, etc
1
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.
1
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.
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
Show replies