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

Subject: Re: [boost] [paired ptr] Proposing a new smart pointer object formanaging bidirectional relationships between objects
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-05-04 06:52:50

Dan Walters wrote:
> Rob Stewart wrote:
>
> >That's an MSVC-specific warning.  Use pragmas push, disable,
> > and pop, conditionally compiled for MSVC, to manage that warning
>
> For MSVC, warning 4355 is disabled in the paired_ptr header.

Did you use #pragma warning (push) and #pragma warning (pop) to control its scope?

> >Using Boost.Function makes your callback support more
> > flexible, which makes it more useful to users.
>
> Callback functions are now of type boost::function1<paired_ptr<T,U>*>
> where T is the owner type and U is the pointed to owner type. This

As I said before, do not assume that the object type for the member function pointer is the owner type.  A user may wish to invoke a member function on a different object.

> works well as users can generate global functions to handle the
> callbacks, use static member functions, and even static member
> functions from other classes. Hence for member usage:
>
> class dog
> {public:
> static void connect_to_cat(paired_ptr<dog,cat>* p_paired_ptr) //

The argument type should be a reference since you'll ensure it is never null.  Don't make the library user check that for every callback.

> paired_cat.set_connect_callback(&dog::connect_to_cat);

No, it should be

   paired_cat.connect_callback(this, &dog::connect_to_cat);

Notice that the object type and the member function type are supplied.  The implementation of connect_callback() can create a boost::function, binding the this pointer, and then forward to the boost::function-based overload.

That member function pointer overload isn't strictly necessary, but it is a nice convenience.  That overload must be a member function template since the object pointer's type can differ from the owner type:

template <class T, U>
class paired_ptr
{
public:
   template <class V>
   void
   connect_callback(V *, void (V::*)(paired_ptr<T,U> &));
};

You should support this overload, too:

   template <class V>
   void
   connect_callback(V const *, void (V::*)(paired_ptr<T,U> &) const);

> >I fail to understand the problem.  In each case you are
> > invoking a functor with a reference to a paired_ptr.  (You
> > could even support overloading for const and non-const
> > access.)  What you need is type erasure to make the callback
> > invocation ignorant of how the underlying function is
> > invoked.  IOW, you want a member function pointer invocation,
> > via Boost.Function, say, to look just like calling a
> > non-member function pointer or function object.
>
> 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);

Of course, but that's why I pointed out that you'd use type erasure via Boost.Function and Boost.Bind (or std::bind1st).

> 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.

Yep.

> I opt for settling for global functions and static member functions,
> as it is a simple and flexible solution.

You don't need to leave out non-static member functions with the approach I suggested.

_____
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.