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 11:06:48

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

> Brian Bartman wrote:http://www.newegg.com/Product/ProductList.aspx?
>

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

I agree. There was only three instances within the library's public
interface that I can think of that use either bit or bitfield as a prefix.
you have pointed out two of the three thus far. The last one which shouldn't
be directly (although there are accessors for it's type) is the proxy
reference type which is called bitfield_reference and defined within
bitfield_tuple.

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

As it is currently bitfield_tuple is in the boost namespace and extra parts
external to the class are located within the bitfields namespace. One of the
other names which came up for this data structure was bit_tuple does that
sound any better?

> 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."
>
>
Hmm. I do understand where you are coming from. I'm considering changing it
to simply 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.
>
> The only reason for the current naming is that the structure which the
bitfield_tuple is currently based off of was named bitfield.

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