3 ms·
auto_ptr's copy is broken, so if you copy one the first object loses the reference. Also, it always uses delete on the reference, which means it can't be used f
by Locke1689 14y ago
auto_ptr's copy is broken, so if you copy one the first object loses the reference. Also, it always uses delete on the reference, which means it can't be used for things that don't use delete (like arrays which use delete[]).
- defap 14y agoBefore 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.
- obiterdictum 14y agoThis was just a workaround for the lack of move constructors. The real problem with auto_ptr is that if anything emits a call to auto_ptr destructor at the point where the object pointed to is incomplete (forward-declared), the destructor code won't run, only memory would be freed.