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

Subject: Re: [boost] [gsoc][RFC] Pointer Plus Bits
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-07-27 10:17:31

Brian Bartman wrote:
> On Tue, Jul 27, 2010 at 7:36 AM, Stewart, Robert
> <Robert.Stewart_at_[hidden]>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?

"bitfields" is fine for the namespace name, presuming the library will be named Boost Bitfields.  (See later for spelling considerations.)  The name is suggestive and means that nested names don't need to repeat "bit" or "bitfield."  "bitfields::bitfield_tuple" is more repetitive than I'd like, but not horrible.  Using a "bit" or "bitfield" prefix for every name in the "bitfields" namespace would be silly, so I'm inclined to suggest those prefixes be used for no names.

That leads me to wonder whether the class template should be just "tuple."  That is, fully qualified, it would be "boost::bitfields::tuple."  That could lead to ambiguity, of course, when mixed with other tuple types with using directives in force, but "bitfields::tuple" can be used when those situations arise.  Unfortunately, should this become standardized in the future, std::tuple won't work.  Then again, there is likely to be a good bit of renaming if things aren't put in the std::bitfields namespace.  That is, "std::align," "std::field," etc., may be too broadly applicable to be thought good names, so we needn't choose names for that vague future context now.  Then again, someone else may find a better scheme than comes to my mind presently.

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

OK, yes, bit fields are declared in the context of a class type, but they aren't normal members.  They are called bit fields.  It would be better to use a name like "field" or "bit_field."

That reminds me, an old (1984) C book I own uses "bit field."  C++98 uses "bit-field."  I think "bit_field" is the better spelling as it best encompasses both of those spellings.  That also would suggest the library name be Boost.Bit Fields or Boost.Bit-fields.

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