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

Subject: Re: [boost] [gsoc] Pointer Plus Bits Behavior and Interface
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-07-15 17:21:17

----- Original Message ----- 
From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, July 15, 2010 7:57 PM
Subject: Re: [boost] [gsoc] Pointer Plus Bits Behavior and Interface

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

The bitfield_tuple class will be extended so the user is able to pack a pointer and some bitfields as follows

struct a;
struct b;
struct c;
typedef bitfield_tuple<
    pointer<foo, a>,
    flag<b>,
    flag<c>
>  foo_bool_bool;

This can ge used as 

foo_bool_bool fbb = make_bitfield_tuple<foo_bool_bool>(new foo(), true, false);

get<a>(fbb)->foo_member

if (get<a>(fbb)!=0) {}

This design gives the separated view of each one of  the components as suggested by Joaquin, Stefan.

The question was if we stop there or we provide some kind of smart pointer that stores a pointer but that allows to use the spare bits to store other info. Brian suggested me to rename pointer_plus_bits something  like twiddling_ptr or stuffling_ptr (Brian could you recall the term you used). This class would have as major interface the interface of a smart pointer, but would have also the interface as it was a bitfield_tuple. We can consider that 

twiddling_ptr<foo, flag<b>, flag<c> > 

is  

bitfield_tuple<
    pointer<T, ptr_tag>,
    flag<b>,
    flag<c>
> 

adding the smart pointer operations.

After the Brian's questions and the comments of Joaquin, I think that this pointer_plus_bits (twiddling_ptr) class will introduce more problems than would solve. Between others, it will be difficult to define the operator==() without ignoring the additional bits and be coherent with the smart pointer view.

As the bitfield_tuple, can not have more than a pointer (at least not for now), we could think in providing a specific accessor so no tag is needed

bitfield_tuple<
    pointer<T>,
    flag<b>,
    flag<c>
> pbb;

pbb.pointer()->

This function could be disabled (using SFINAE) if the bitfield_tuple has no pointer member.

Best,
Vicente