>>we'd have to get used to using auto_ptr
>auto_ptr is broken. We should use shared_ptr instead
It has begun!
One of the most enjoyable features of C++ is the arguing over which parts of the language should be allowed.
>auto_ptr is broken. We should use shared_ptr instead
It has begun!
One of the most enjoyable features of C++ is the arguing over which parts of the language should be allowed.
The vast majority of allocated objects have unique ownership semantics, not shared. If you use shared_ptr everywhere, it's far too easy for your design to degenerate into object soup.
You mean that it's usually better design to have only one "owner" of an object? That's true.
It's worth noting that shared_ptr is also necessary for containers, so you might get into a habit of using it even if you're not creating multiple references.
Edit: Of course I'm being a bit stupidly snarky here, obviously if you have a standard container you need a shared_ptr, or an intrusive_ptr, or some other pointer, the moral of the story is that std containers aren't good for holding owned pointers in C++03.
I don't think boost ptr_containers are particularly good either, but that's mostly because of the huge cost of putting the string '#include "boost/' in your code.
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 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.