[boost] Re: bidirectional pointer proposal

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