Date: 2002-06-18 05:58:30
> From: Yitzhak Sapir [mailto:yitzhaks_at_[hidden]]
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk