Boost logo

Boost :

Subject: Re: [boost] [gsoc][review/comments] Request community input on project interface
From: David Abrahams (dave_at_[hidden])
Date: 2010-06-21 13:18:41


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.

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

If you had said “Specifically, bitfield_tuple's get function returns a
proxy reference” it would have been crystal clear.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk