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<>
> > 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
> > std.
> > An interesting related question is "why does shared_ptr have
> Exact, thats was my point. Does it need reset() and assign
> Won't a immutable shared_ref cover the semantics better? If we
> reset() and/or assign operation then they should not break the
> 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
shared_ptr<foo> p1(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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk