On Sun, Jul 25, 2010 at 2:05 PM, Stefan Strasser <strasser@uni-bremen.de>wrote:
Zitat von Brian Bartman <bbartmanboost@gmail.com>:
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