Re: [boost] [gsoc] Pointer Plus Bits Behavior and Interface

Subject: Re: [boost] [gsoc] Pointer Plus Bits Behavior and Interface
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-07-15 13:57:43

Joaquin M Lopez Munoz wrote:
> David Abrahams <dave <at> boostpro.com> writes:
> > On Jul 15, 2010, at 1:09 PM, Andrew Sutton wrote:
> > > Rob Stewart wrote:
> >
> > >> One could argue that the bits should be evaluated to
> > >> produce the Boolean result as easily as evaluating the
> > >> pointer.  There are two aspects in pointer_plus_bits
> > >> and they shouldn't be obscured or conflated.
> > >
> > > I strongly disagree with using views in the design of
> > > this data structure.
> > > It's not such a complex concept that you would need to
> > > explicitly decouple
> > > its concerns via views. You end up designing a
> > > pointer+bits that can't be
> > > used natively as a pointer or bits.
> >
> > I agree with Andrew.
>
> I disagree with Dave and Andrew. There is no natural concept
> around "a pointer plus some bits". These are packed together
> to save space, which is an aspect completely orthogonal to
> whatever purspose the pointer and the bits serve (separately).

I agree almost completely.

> To me, pointer_plus_bits should be as similar as possible
> to having two members, one a pointer the other the bits, so
> that for instance the following
>
> class X
> {
>   ...
>   pointer ptr;
>   bool    b;
> };
>
> can be rewritten as
>
> class X
> {
>   ...
>   pointer_plus_bits<...> pb;
> };
>
> so as to save memory, with as little change from the original
> situation as possible (for instance, instead of x.ptr one would
> say x.pb.ptr() and so forth). Overelaborating on an
> concept+bits concept seems to me to be missing the point.

That's a nice analogy.

The alternative is to declare that pointer_plus_bits is just a pointer that happens to carry some bits, which was Andrew's emphasis.  When used as a pointer, it works like any good smart pointer.  When the payload is required, an accessor provides some alternative view.  There's some legitimacy to that view, but I think it is largely misguided because, as you point out, a pointer_plus_bits is like a struct with both a pointer and a payload and favoring one member over the other is inappropriate.

Now, we could rethink the extrinsic view approach and instead provide two accessors that return a smart pointer and a payload object.  That is, one calls a member function to get the equivalent of Joaquin's pb:

   x.pb.ptr->foo() vs x.pointer()->foo()
   x.pb.b          vs x.bits()

BTW, I've been using the general term "payload" but named the member function "bits" because the class name is, currently, "pointer_plus_bits."  It might be useful, especially in light of the recent consideration of permitting the treatment of the extra bits as a small integer value, to name the class "pointer_with_payload" or something like that.  ("data" and "value" are shorter than "payload" so they're probably better choices.)

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