RE: [boost] Re: Conversion from auto_ptr to scoped_ptr?

From: Bjorn.Karlsson_at_[hidden]
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.

Bjorn