> From: Yitzhak Sapir [mailto:email@example.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.