I like the general idea of your bidi_ptr. I haven't really read your implementation yet, but your description sounds promising.
I don't really like the name bidi_ptr though. Bidirectional is always spelled out in the Standard library. But bidirectional_ptr is rather long. How about paired_ptr?
- using assignment for connecting peers warps the 'normal' modus operandi of assignment, should I rather us an auxillary function ?I think a member function or a free function called connect would be clearer.
I'd prefer the free function because I think the fact that connect(a,b) does the same as connect(b,a) is more natural than the fact that a.connect(b) does the same as b.connect(a). But that may just be me. ;)
- usually, I would make bidi_ptr<B,A> a friend of bidi_ptr<A,B>, because it needs access to its peers internals in order to not work recursively. This doesn't work with my compiler if B is the same as A, the compiler complains that any class is implicitly its own friend. Therefore all data is currently public.You could add a nested class in the private section of bidi_ptr, say prevent_friend_to_self. Then you could declare bidi_ptr<B, A> to be a friend of:
bidi_ptr<A, if_<A==B, prevent_friend_to_self, B>::type >
(That's pseudo-MPL. I don't currently use the MPL well enough to have memorized the correct syntax to do. It should all be in the docs though.)
It's a bit of a mess, but it should work. Perhaps some clever Booster will think of a better way. ;)
Nothing. You could assert that the peer pointer is not null, but don't do anything about it.- what should operator-> or * do when there is no peer attached ?
IMHO.
Regards,
Dirk Gerrits
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
