Re: 2nd: [boost] shared_ptr proposal

From: williamkempf_at_[hidden]
Date: 2001-07-13 09:12:38

--- In boost_at_y..., Christian Thäter <chth_at_g...> wrote:
> > 
> > What are the complexity requirements of the boost::shared_ptr<> 
member
> > functions?
> > 
> > He asks, if I understand correctly, not how boost::shared_ptr is
> > currently
> > _implemented_, but how it's _defined_.
> > 
> > A question that will become more important if/when shared_ptr 
moves into
> > std.
> > 
> > An interesting related question is "why does shared_ptr have 
use_count?"
> > 
> 
> Exact, thats was my point. Does it need reset() and assign 
operations?
> Won't a immutable shared_ref cover the semantics better? If we 
provide a
> reset() and/or assign operation then they should not break the 
shared
> resource as they do now so either update all copies or none.

Excuse me for breaking in where I probably don't belong, but I'm not 
sure I'm understanding what you're asking.  Do you expect to have the 
following semantics?

shared_ptr<foo> p1(new foo());
shared_ptr<foo> p2(p1);
p1.reset(new foo());
assert(p1.get() == p2.get());

That certainly seems to be what you mean when you say "they should 
not break the shared resource as they do now so either update all 
copies or none."

If this is what you mean, I don't find such semantics to be 
intuitive, or even useful for anything but the most obscure designs.  
I wouldn't argue against inclusion of a smart pointer that works this 
way (provided concrete uses can be illustrated), but I'd definately 
argue against any desire to change shared_ptr<> itself to behave in 
this manner.

Bill Kempf