Re: [boost] Re: smart_ptr suggestion: Support decrementing shared_ptr'scount, forself-references

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-05-27 16:05:23

Chuck Messenger wrote:
>
> Consider that A and B may implement various "interfaces" (i.e. inherit
> from 1+ abstract base classes w/o member variables).  I can't just use
> multiple inheritance (i.e. AB inherits from each interface that
> either A
> or B needs), because, for one thing, there can be more than one A
> and/or
> B in the group.  How would you differentiate between them?
>
>> pass a B_impl* to A_impl's methods that need it; keep a
>> B_impl* or a weak_ptr<B_impl> in A_impl.
>
> These approaches greatly complicate the code.  Suppose I have a host
> of functions defined at A and B level -- nothing defined at A_impl and
> B_impl.  To do what you're saying, for one thing, I'd have to have a
> parallel set of methods for A_impl and A (and for B_impl and B).  But
> it's worse than that -- I also need a parallel set of external
> functions (methods of other functions, etc), which can accept either
> an A or an
> A_impl.  It's just not workable.

If you show me a real example that demonstrates what you're saying above, I
will (try to) refactor it to eliminate the cycles. If you don't, well, I
won't. :-) There are cases where a group of "strongly" interconnected
(shared_ptr links) objects cannot be transformed into a group object that
owns "weakly" interconnected (weak_ptr links) objects but these cases are
very rare.

FWIW the experimental "garbage collector" in
libs/smart_ptr/src/sp_collector.cpp can collect cyclic shared_ptr
structures...