Boost logo

Boost :

Subject: Re: [boost] [gsoc][RFC] Pointer Plus Bits
From: Brian Bartman (bbartmanboost_at_[hidden])
Date: 2010-07-27 09:25:27

On Tue, Jul 27, 2010 at 7:36 AM, Stewart, Robert <Robert.Stewart_at_[hidden]>wrote:

> Brian Bartman wrote:
> "align" would be a better name. "Bit" is useless in context.
The original name was going to be align, however I encountered a naming
conflict with boost.Type Traits' align. Then after implementing it as
bit_align, I later move all of the templates which make up the
bitfield_class template interface into a separate namespace (namespace
bitfields). So fixing that is quick.
So as a general question should the namespace have a name other then
bitfields? Would fields be a better name? And should the bitfield_tuple data
structure be within that namespace as well?

> When you document this mechanism, I suggest wording more like, "Ensures the
> offset of the next bit field is divisible by the supplied value."
Thanks for this, I was have some trouble figuring out how exactly to word
this for my documentation.

> > filler<std::size_t> -> bits to be skipped.
> Instead of "filler," how about "padding," "reserve," or even "ignore?"
I'm going to go with padding.

> I think "field" would be a better name. "Member" is too suggestive of
> classes and the parts in this context are called "bit fields," right?
The initial intent of the interface of the bitfield_tuple was to make it
feel sort of like a class/struct, while the user was supplying the template

For instance,

struct rgb565_t {
    unsigned char red:5;
    unsigned char green:6;
    unsigned char blue:5;

would become something along the lines of,
struct red;
struct green;
struct blue;

typedef bitfield_tuple<
    member<unsigned char, red, 5>,
    member<unsigned char,green, 6>,
    member<unsigned char,blue,5>
> rgb565_t;

> > storage<typename> -> uses the supplied type for internal storage.
> I presume you mean that dictates the underlying storage type for the entire
> bitfield_tuple. I'm not sure I like that interface. I think two distinct
> types, one that computes the storage type and one that requires it (as the
> first template argument) might be better. That implies, of course, creating
> distinct names. Perhaps "bitfield_tuple" and "typed_bitfield_tuple?" (The
> latter is rather verbose, but no more so than "storage<some_type>" in the
> current scheme.)
> _____
> Rob Stewart robert.stewart_at_[hidden]
> Software Engineer, Core Software using std::disclaimer;
> Susquehanna International Group, LLP
> IMPORTANT: The information contained in this email and/or its attachments
> is confidential. If you are not the intended recipient, please notify the
> sender immediately by reply and immediately delete this message and all its
> attachments. Any review, use, reproduction, disclosure or dissemination of
> this message or any attachment by an unintended recipient is strictly
> prohibited. Neither this message nor any attachment is intended as or should
> be construed as an offer, solicitation or recommendation to buy or sell any
> security or other financial instrument. Neither the sender, his or her
> employer nor any of their respective affiliates makes any warranties as to
> the completeness or accuracy of any of the information contained herein or
> that this message or any of its attachments is free of viruses.
> _______________________________________________
> Unsubscribe & other changes:

Brian Bartman

Boost list run by bdawes at, gregod at, cpdaniel at, john at