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-16 10:42:44

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

> 
> Scott McMurray wrote:
>> On 15 July 2010 21:00, Andrew Sutton
>> <andrew.n.sutton_at_[hidden]> wrote:
>> >
>> > I would think that the point of creating this particular data type
>> > (pointer_plus_bits) was to emphasize the pointer aspect and
>> > less so the "pair".
>>
>> I think that's a point-of-view difference.  When I heard of it, I
>> immediately thought of "compressed pair with non-empty things".
> 
> Emphasizing the tuple aspect may be useful.  The generalized bitfield_tuple is a reasonable building block, but if one of the elements is a pointer, it seems a name with "pointer" in it would be better.  For that, just reversing the terms might do well.  I also suggested, elsewhere, that "bits" be replaced with "data," "values," or something like that.  Therefore, consider these combinations:
> 
>   data_and_pointer
>   data_plus_pointer
>   data_with_pointer
>   values_and_pointer
>   values_plus_pointer
>   values_with_pointer
> 
> "data" is shorter, so I favor it over "values."  "data_and_pointer" lends itself to an acronym, "DAP," which might prove useful.

The initial goal of the bitfield_tuple was to emulate bitfields structures. Now that we will have pointers in, we can think of this class a compressed tuple, on which each member takes only the needed bits. 

The Brian's project concern also with the ability to work with storages that will go out of the word boundary. So maybe compressed_tuple could be a better name that allows to put in whatever data.

Best,
Vicente