From: Dirk Gerrits (dirk_at_[hidden])
Date: 2003-01-08 12:10:24
Hi Ulrich,
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. ;)
> - what should operator-> or * do when there is no peer attached ?
Nothing. You could assert that the peer pointer is not null, but don't
do anything about it.
IMHO.
Regards,
Dirk Gerrits