Chris Just wrote:
Jonathan Turkanis wrote:
There is a policy-based pointer, based on the Loki SmartPtr, coming up for review soon which can emulate an auto_ptr and allows deletion policy to be specified as part of the 'storage policy'.
I don't know much about the Loki SmartPtr, but it sounds like it might be a little hard to use if you need to setup policies...
It comes with a collection of ready made policies, including policies for auto_ptr and move_ptr (at least it will soon).
I wanted to create a very simple AutoPtr that was essentially the same as the STL auto_ptr (and backwards compatible with it).
Unfortunately, you haven't (see below). Furthermore, auto_ptr is widely recognized as unsafe because it is too easy to transfer ownership unintentionally.
I only looked very briefly, but I don't see how your auto_ptr can be returned from functions. Also, why do you need the m_Owner variable?
Correct me if I'm wrong, but wasn't there a specific reason why the STL auto_ptr was made so it couldn't be passed to or returned from a function?
This was true of the initial version. The standard version, which is version 3, implements a flavor of move semantics (and it doesn't quite work).
Anyways, if you want to pass or return the pointer to/from a function, just use the .get() or .release() functions.
But this subverts the resource management system.
I need the m_Owner variable to tell me if I own the pointer before I delete it.
For auto_ptr, checking that the stored pointer is non-null should be sufficient. Jonathan