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[]).
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.
The 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.
Sure. 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.
This 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.
