From: Chuck Messenger (chuckm_at_[hidden])
Date: 2003-05-27 22:26:24
Peter Dimov wrote:
> 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
>>or B needs), because, for one thing, there can be more than one A
>>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. :-)
Well, it's in too much flux right now -- perhaps if I ever finish it,
I'll post it. It's a concurrency library - an implementation of the API
described in Concurrent Programming in ML.
> 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
Thanks -- that sounds interesting, too -- I've also been told of
cyclic_ptr, in the contributions. Even if one/both don't do the job,
they should give me some ideas...
- Chuck Messenger
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk