Currently, this works only over integral types, although there are plans to extend this in later versions of the data structure. bitfield_tuples correctly work with different types of endianness as well as provide the mechanisms to allow users to explicitly define the size of the structure's storage space.
I think you need to define what you consider to be “correctly working with different types of endianness.”
OK I'll do my best to better describe the internal workings of the type with regards to the endianness of the storage type, with in my documentation.
The bitfield_tuple is a tuple like sequence of elements but, instead of providing direct access to an instance of a type, a proxy to the element stored within the bitfield_tuple is returned. This is similar to std::vector<bool>'s reference type.
Example bitfield_tuple declaration,
struct red; struct green; struct blue;
typedef bitfield_tuple< storage<unsigned int>, member<int,red,5>, member<int,green,6>, member<ing,blue,5>
bft_example;
The internal storage type which all of the bitfields are stored in is specified by the storage template. The members are used to specify the different bitfields which are to be stored within that storage type. The member template is specified the exact same way a normal c++ bitfield would be specified inside of a struct or class.
int red:5;
Not valid C++ AFAIK.
Sorry I should clarify that. struct a { ... int red:5; ... };
member<int,red,5>
A member template is specified in the order of: type, name, width of bitfield.
So these “names” (struct tags) are a way of referring to different fields? Is it possible to refer to them by index?
You can use index or name which ever you prefer.
The order the member templates are given in is the order in which they are stored within the bitfield_tuple. However, the storage template does not take up an index within the bitfield_tuple. So the template member<int,red,5> will be stored at index 0. Each member template requires a name be specified; this is for ease of access, later described in the get function. Each name must be unique within a single bitfield_tuple. The width of the bitfield is handled internally. The starting point for each bitfield is the bit after the previous bitfield, or 0 if it's the first bitfield.
I think you need to define “after.”
I can do that and I'll be sure to note just how it works in my documentation.
bitfield_tuple interface summary:
Default constructor, copy constructor, and a constructor which allows for the construction over an initial value which is of the same as the storage type.
bitfield_tuple(); bitfield_tuple (bitfield_tuple const&); bitfield_tuple (storage_type);
That last one should be explicit because of the possibility of narrowing.
OK thanks. I'll do that.
Assignment operators for assignment from the storage type, similar to the constructor above, and copy assignment.
bitfield_tuple const& operator=(storage_type); bitfield_tuple const& operator=(bitfield_tuple const&);
The get function operates similar to the boost.tuple with slight modification. Specifically, the get function will return a reference type.
?? boost.tuple's get<> doesn't return a reference? How can you return a reference to three bits? Didn't you already tell us you were using proxies?
Sorry. It seems I was unclear again. its a proxy reference tpye that acts as a front end to the internal bits.
I hope you find these comments helpful.
Thanks for the fast reply, the information was extremely useful.
Regards,
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- thanks, Brian Bartman