I'm puzzled.  Why does this create a dependency on auto_ptr<> ?
At Monday 2002/06/17 14:57, you wrote:

> 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

Victor A. Wagner Jr.      http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
              "There oughta be a law"