Chuck Messenger wrote:In general, the abstraction is: you have a group of intra-referential objects. When any of the group is constructed, they are all constructed (so that the master count is temporarily > 1), and the master count is reset to 1. When the master count goes to 0, the group is destructed. Hence, the group only remains alive as long as there are any external references (and as long as the intra-group references remain static).
In the situation you describe, A logically contains a B and B logically contains an A, so A and B aren't independent; they actually form an AB object. There is nothing to be gained from separating A and B as this doesn't eliminate a dependency. If A and B are optional (but still tightly coupled) parts of AB, the way I'd express this would probably be
class AB { shared_ptr<A_impl> ai_; shared_ptr<B_impl> bi_; };
There are several ways to allow A_impl and B_impl to communicate: store an AB* pointer in each;
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.
- Chuck
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
