Re: [boost] [gsoc][RFC] Pointer Plus Bits

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

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  http://www.sig.com
>
> 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:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
thanks,
Brian Bartman