> From: Yitzhak Sapir [mailto:yitzhaks@actimize.com]
>
> Most of us don't change <memory> on a regular basis.  So why
> is the dependency problematic?  What do you lose from it?  I
> would like to have this, but for me, this would be syntactic
> sugar, since I can accomplish the same thing with calling
> release() before passing it to the constructor.  Besides,
> standard library headers sometimes include a lot more than
> you might think they include.  I think dependencies should be
> few, but dependencies are not that bad when the element they
> depend on is pretty much constant.

I agree that the physical dependency from #including <memory> is a minor issue. The coupling between scoped_ptr and auto_ptr is a limitation because 0) scoped_ptr cannot exist without auto_ptr and 1) the client of scoped_ptr needs to understand auto_ptr (as of the rule "you'll pay for what you don't know, for sure").

For most of us, these are obviously non-issues, but it's still an increase in complexity. As much as I value syntactic sugar, I don't think that the code would become much clearer, which is why I don't think that scoped_ptr should know anything about auto_ptr. It's a minimalist tool.

 
 
> > 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.
>
> And you force initialization in the constructor
> initialization list if it is a class member.

Yep, for those who are brave enough to use auto_ptrs as class members.

Bjorn