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

Subject: Re: [boost] [gsoc][review/comments] Request community input on project interface
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2010-06-22 09:27:17

Brian Bartman wrote:
> 
> On Mon, Jun 21, 2010 at 1:18 PM, David Abrahams <dave_at_[hidden]> wrote:
> 
>> At Mon, 21 Jun 2010 13:02:29 -0400,
>> Brian Bartman wrote:
>> >
>> > > > 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.
>>
>> I don't think internal workings is what I'm interested in.  I *would*
>> like to know what kind of storage layout in memory I get on both big-
>> and little- endian machines, though.  If you could give rationale
>> about why those design choices are the “correct” ones too, it would be
>> a bonus.
>>
> 
> The internal memory access and modification is managed by bitfield (which
> is
> currently in the boost vault) and was written by my mentor Vicente Botet.
> I'll have to get back to you after I know more about how his data
> structure
> handles endianness.
> 
> 

The bitfield class expect an INTEGER-LIKE storage type. Usually the storage
type will be a native type.
In this case, the conversion to/from a specific endian type, can be made at
once for all the bitfields of the same storage, as it was an other integer
type, i.e. at the I/O level.

We can use also an endian aware integer type as storage, such as
boost::integer::endian<> as defined in Boost.Endian. In this case each
bitfield read access results in a conversion from the endian storage to the
native type plus the mask operation itself and each bitfield write access
results in conversion from the endian storage to the native type,  the mask
operation itself plus conversion from the native storage to the endian type.
These conversions are done transparently through the INTEGER-LIKE conversion
operator and assignment.

Best,
Vicente

-- 
View this message in context: http://old.nabble.com/-gsoc--review-comments--Request-community-input-on-project-interface-tp28950756p28960042.html
Sent from the Boost - Dev mailing list archive at Nabble.com.