Re: [boost] [gsoc][RFC] Pointer Plus Bits

Subject: Re: [boost] [gsoc][RFC] Pointer Plus Bits
From: Brian Bartman (bbartmanboost_at_[hidden])
Date: 2010-07-25 14:32:52

On Sun, Jul 25, 2010 at 2:05 PM, Stefan Strasser <strasser_at_[hidden]>wrote:

>
> Zitat von Brian Bartman <bbartmanboost_at_[hidden]>:
>
>  typedef bitfield_tuple< pointer<int, ptr> > ptr_1;
>> typedef bitfield_tuple< pointer<int, ptr>, flag<b1>, flag<b2> >
>>
> ptr_plus_two_bools;
>
>> typedef bitfield_tuple< pointer<int, ptr>, member<unsigned int,color,2> >
>>
> ptr_plus_two_bit_color;
>
>
> I don't quite understand the rationale for all the differences between
> "pointer" and "member", but besides that it looks good.
>

for example, you might want to store an integer that is always a multiple of
> 4 so the 2 lower bits aren't used. why is the masking/shifting restricted to
> pointers? i.e. why is there any difference between member<> and pointer<>
> besides a different interface/view/return type of get<>()?
>
>
Pointer has one additional parameter which isn't currently isn't used in
these examples. It allows the user to specify an integral_constant as a mask
for the value bits of the pointer.

There is one more field type which I'm going to add which will all the user
to supply both a mask and a policy specifying how to store and retrieve data
from within the storage type OR simply provide a mask type which will act to
indicated the value bits within the type being stored. So for instance you
could do what you are talking about and always store data within the lower
to bits of an integer.

>  flag<typename> -> boolean version of member.
>>
>
> how does flag<> differ from member<bool>?
>
>
There really isn't any difference Other then less typing.

>
>  filler<std::size_t> -> bits to be skipped.
>>
>
> what's the reason for letting the user control how the bits are stored?
> (specified order, filler<>, bit_align<>)
>
>
>
The rationale behind allowing the user to control the bits is so that the
bitfield_tuple can be used to construct packet header.

>
>  typedef bitfield_tuple<
>>    member<unsigned char, red, 5>,
>>    member<char, green, 6>,
>>    member<unsigned int, blue,5>
>>  >  rgb565_t;
>>
>> The bitfield_tuple takes ordered named template parameters
>>
>
> the member naming is nice, but it would also be nice if this could be
> skipped, because people are used to indexing and might even replace a
> boost::tuple with a bitfield_tuple.
> (this would imply that the "name" parameter and the "size_t" parameter are
> switched so that the "name" can have a default.)
>
>
OK I'll take that into consideration. It was something I had considered
allowing for. I'll see if within the next iteration of this data structure I
can't make the naming optional.

>
>     p1.get<0>() = &i;
>>
>
> in case you didn't already plan for that, there should be a metafunction
> that returns the return type of get<>(). (element<N,T> in Boost.Tuple)
> the user might need this for example in order to use the "pointer view" as
> an iterator.
>
>
>
I do have more then one way of accessing the proxy reference type that comes
back from get. Its a fusion sequence and I provide additional meta functions
external to the bitfield_tuple itself for accessing the proxy reference
type.

Thanks for the feedback

> thanks,
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
thanks,
Brian Bartman