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. :-)
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 structures...
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
