Re: [boost] [paired ptr] Proposing a new smart pointer objectformanaging bidirectional relationships between objects

Subject: Re: [boost] [paired ptr] Proposing a new smart pointer objectformanaging bidirectional relationships between objects
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-05-04 07:01:44

vicente.botet wrote:
> From: "Dan Walters" <dan683_at_[hidden]>
> >
> > The problem is that to call a normal function, the
> > arguments would be:
> >
> > void callback_function(<paired_ptr<T,U>* p_ptr);
> >
> > For a member function it would be:
> >
> > void callback_function(T* this, <paired_ptr<T,U>* p_ptr);
> >
> > Obviously, the this pointer is available in member
> > functions and so is
> > passed invisibly to the function. So the parameter lists
> > are different
> > and not inter-operable between global functions and member
> > functions.  This can be overcome using std::bind1st.
>
> I think this is what Rob is saying. You need just to define
> the prototype for the callback. If the user needs other
> arguments bind will help.

Exactly.

> >>I don't know why I don't like the name paired_ptr,
> >> one_to_one_ptr could be an alternative.
> >
> > How about bi_ptr? The object is then clearly a
> > bidirectional pointer.  one_to_one still seems ambiguous
> > to me.
>
> You are right one_to_one is no better. The class represents
> one of the ends of a bidirection association, mayb we have here the

pairing_ptr?
linking_ptr?
connection?
link?
association?

Some of those imply n-ary support, not just one-to-one, of course.

> > Infact, is this library even a pointer? It never manages
> > memory in any
> > way. Except for the -> operator and the get() function (like
> > smart_ptrs) it doesn't really have any responsibilities
> > that a pointer
> > has, the name is only intended to make clear that it isn't
> > the object
> > itself. But a pointer is usually a container for a single
> > object, and
> > this is not a container. Maybe it is a reference? But this would
> > confuse the -> operator and the get() function...

I think it is quite reasonable as a smart pointer.  There are many uses for that class (no pun intended) of thing.

> >>I will see this class as one more in a Association library
> >> that could include other kind of associations, as
> >> one_to_many, many_to_one, many_to_many,...
> >
> > While this immediately seems obvious, the one_to_one relationship is
> > quite special. Here, both sides of the relationship share
> > authority. A
> > one to many or many to one relationship clearly has a single
> > authoritative element - being the one rather than the many.
> > How would
> > these differ from a pointer container? And the many to many
> > relationship is already dealt with in a way by the bimap library (as
> > you later pointed out).

Both arguments have merit.  There are other approaches for one-to-many and many-to-many relationships.  However, as you pointed out above, one of the distinguishing characteristics of your class is that it does no memory management.  It also differs in that it provides callbacks to indicate when associations are formed and severed.  Your class manages the associations and not the objects.  Consequently, were that extended to one-to-many and many-to-many associations, it would remain distinct from other solutions.

> > The one-to-one relationship is a pointer to pointer, while any
> > relationship involving a 'many' starts to become a container and in
> > any container, there must be an authoritative element to manage the
> > contents.

I disagree.  It would be a container of pointers with callbacks as pointers are added and removed.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.