[boost] Re: auto_ptr in collections

From: Paul Jensen (pdjensen_at_[hidden])
Date: 2000-03-02 17:30:52

Steve Clamage wrote:
> John Nagle wrote:
> >    Did the use of collections with auto_ptr elements ever get fixed,
> > or is that still broken?
> ...
> The various complaints about auto_ptr all boil down to having
> conflicting sets of requirements. They can't all be satisfied
> at once. I think a future C++ standard could have a collection of
> safe-pointer classes, each with different semantics.

I've been trying to find a reasonable safe-pointer representation to hold the
ownership of a class data member - ie, replace class C { TYP *t; ... }; with
class C { class_template<TYP> t; } where the class C is intended to have value
semantics, and the cctor and op= for class_template<TYP> either copy the object
of type TYP, or share it. 

C's members need to change t's value, and that seems to require auto_ptr as the
appropriate argument type for passing the ownership in and out.

auto_ptr<TYP> fails to work unless C's cctor and op= deal with it explicitly.

Boosts shared_ptr<TYP> seems to address the problem, but I've found no way to
modify its value since there is no release() capability. get() followed by
reset() results in a dangling pointer, and swap() just postpones the agony. I
can't seem to convert shared_ptr => auto_ptr.

Since this situation is akin to the problem of a collection of owning pointers,
I thought the solution would be the same. 

I'm attaching a short class declaration to sketch what I'd like.

Pointers?
        Thanks,
                Paul
-- 
Paul Jensen	Agile Image Movers	http://agileimage.com