> From: Markus Schöpflin [mailto:markus.schoepflin@ginit-technology.com]
[snip]
> Hmm, I did some further thinking on this and I simply can't see the
> difference between the current shared_ptr, which offers a
> conversion from
> auto_ptr and my suggestion for scoped_ptr.
>
> Could you enlighten me, Peter? Or anybody else?
>

I'd argue that introducing a dependency to std::auto_ptr is not in the best interest of scoped_ptr. It seems to me that scoped_ptr differs from shared_ptr in design intent - scoped_ptr should know and require as little as possible (but no less), whereas shared_ptr takes pride in being smart.

There are two idioms that can be used to approximate scoped_ptr in the scenario where an auto_ptr is returned from a function:

0) Declare the auto_ptr const. This comes very close to the behavior of scoped_ptr, with the exception that you can reset the scoped_ptr, but not the auto_ptr.

1) Use solution 0 together with scope (pun intended): { const std::auto_ptr... }. This takes care of most cases where the pointee must be deleted at a certain location in the code.

Armed with these tools, the most compelling argument that remains for adding the conversion from auto_ptr to scoped_ptr is stating the intent of code more clearly; but does the added value really outweigh the cost of the added dependency?

Bjorn