At Mon, 21 Jun 2010 12:39:40 -0400, Brian Bartman wrote:
Hello,
I'm currently working on my GSoC project and I wanted some feedback from the community about the interface of a data structure I'm working on called a "bitfield_tuple". The bitfield_tuple makes it easy and simple to create and use specific bitfields.
Cool.
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.”
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.
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?
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.”
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.
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?
There are two ways to use the get function. The first way is by using a unsigned integral constant as an index:
bft_example temp; temp.get<0>(); // returns a proxy reference to the bitfield represented by member<int,red,5>
The second way to use it is to call get using the name provided to the member parameter:
temp.get<red>(); // does the same thing as get<0>();
I provide both const and non const versions of both functions.
The bitfield_tuple is also a boost.fusion sequence. It models an associative array type by using the following category:
struct bft_category : boost::fusion::random_access_
traversal_tag, boost::fusion::associative_tag { };
Good! I hope you find these comments helpful. Regards, -- Dave Abrahams BoostPro Computing http://www.boostpro.com