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
-
-
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.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
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,
@DanielMicay '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 -
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.
- 4 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.