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

Subject: Re: [boost] [gsoc][RFC] Pointer Plus Bits
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-07-25 14:05:19

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<>()?

> flag<typename> -> boolean version of member.

how does flag<> differ from member<bool>?

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

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

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

thanks,