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

Subject: Re: [boost] [paired ptr] Proposing a new smart pointer object for managing bidirectional relationships between objects
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-05-03 08:47:38

Dan Walters wrote:
>
> Doumentation only is available here: (this is a google doc and is
> continually being updated)
>
> http://docs.google.com/View?id=dc33pnfx_442s22z7d6
>
> I am posting here in the hope it will generate suitable interest that
> it may be worth developing as a full library for submission.

The idea is interesting, but I'm not sure whether I'd use it.  The example you provide is not compelling.  I'd like to see some real, useful examples to motivate the need for paired_ptr.

FYI: I only looked at the document, not the code, when generating the following comments.

You asked in the document, so I'll mention that Boost doesn't use mixed case and doesn't prepend "C" to class names.  You should adjust your examples accordingly.

None of the code appears to be formatted properly.

Your "Usage" section should use initialization rather than assignment for paired_cat and paired_dog.  Indeed, from the surrounding text, it would seem that calling set_owner() is the only way to indicate the owner and that means it is possible to not specify an owner.  It would be better if the constructor required an owner so the user is forced to initialize the instance with one.  Doing so will eliminate the "unfortunate" sentence.

(Note that you can still support set_owner() to permit changing ownership, and that the instance can be initialized with a null pointer, but that initializing from a null pointer and not calling set_owner() later is a user error of commission not omission.)

The type is named "paired_ptr" so why does "pair" appear in member functions like "connect_pair" and "disconnect_pair?"

Looking at the "Callback Functions" section, it appears that constructor overloads accepting the owner plus either or both of the callback functions would be in order versus requiring individual function calls.

The callbacks should be boost::functions for maximum flexibility.

You have assumed the size of a member function pointer is the same as an ordinary pointer, but that's a false assumption.  It depends upon platform.

Rather than a fat and skinny version of paired_ptr, perhaps the callbacks could be stored in a separately allocated object that is created only when needed.  Indeed, using SBO you could keep the size to just two pointers.  When there are no callbacks, use just the data members, but when there are callbacks, store everything in a separate allocation.  (If the two data members point to the same address, it will be the address of memory allocated on the free store to hold two object pointers and two member function pointers.  If they refer to different addresses, then there is no free store allocation and there are no callbacks.)

The callbacks should know the paired_ptr invoking them, because a legitimate reaction might be to modify the paired_ptr's state and using boost::function, the callback may not be a member function or there may be more than one in a UDT and the callback would need to disambiguate.

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