Re: [boost] [gsoc][review/comments] Request community input on project interface

Subject: Re: [boost] [gsoc][review/comments] Request community input on project interface
From: Brian Bartman (bbartmanboost_at_[hidden])
Date: 2010-06-21 13:02:29

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