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