3 ms·
Before the days of std::move, auto_ptr's copy modeled an ownership-transfer semantic in a more efficient way than could be accomplished by shared_ptr (no refcou
by defap 14y ago
Before the days of std::move, auto_ptr's copy modeled an ownership-transfer semantic in a more efficient way than could be accomplished by shared_ptr (no refcount churn). It wasn't broken; one must have simply known when it was appropriate to use.
Consider a helper function that returns a heap-allocated object and think whether auto_ptr or shared_ptr better modeled the function's intent of giving ownership of the object to the caller.
- shrughes 14y agoThe problem with auto_ptr is that it put these ownership-transfer semantics in the copy constructor instead of something more explicit. A scoped_ptr type that has a release() method is far more useful and safer than auto_ptr.
- defap 14y agoSure. I was more responding to the claim that shared_ptr should always be preferred to auto_ptr. I agree that scoped/unique_ptr fixed a lot if auto_ptr's pitfalls.