Re: [boost] Boost.Integer makeover

Subject: Re: [boost] Boost.Integer makeover
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-11-28 15:37:22

John Maddock wrote:
>
> > Overview
> >
> > s/specifications are/specifications for these types are/
> > s/The 64-bit types...in the C++ standard./The 64-bit types
> required by the
> > C standard are used as models.  If <stdint.h> is available
> on a given
> > platform, those typedefs are used as the definitions for the boost
> > namespace typedefs.  Otherwise, or if long long is not provided,
> > <boost/cstdint.hpp> provides its own definitions.
>
> Not quite, if there's no long long then boost/cstdint.hpp can
> hardly provide it's own definitions ;-)

That's not quite true.  There may be an extension type that can be employed.

> Updated to, hopefully, make this clearer:
>
> "The specifications for these types are based on the ISO/IEC
> 9899:1999 C Language standard header <stdint.h>.
> The 64-bit types required by the C standard are ['not
> required] in the boost header,
> and may not be supplied for all platforms/compilers, because
> [^long long] is not [yet] included in the C++ standard."

If your understanding of the behavior is accurate, that sounds good.

> > Integer Type Selection
>
> > These are not doc comments: I would think adding
> uint_fast_t would be less
> > confusing, though using int_fast_t with unsigned types must
> probably
> > continue to work for backward compatibility.  The output
> type ought also to be accessible as "type."
>
> Will change to use ::type.  I'm not convinced about adding
> yet another trait, when this one will do though...

I suggested adding "type" because "fast" matches the name in other traits for the same purpose.  Thus, "type" because that's the norm for such things, and "fast" because it is consistent with the other "bag" traits.

I understand your concern about adding a type, but there are signed and unsigned variants for other purposes, so it seems odd that this one doesn't follow.

> > Sized Types
> >
> > This is not a doc comment: The output type ought to be
> > accessible as "type," though you'd probably need to retain
> > "least" for backward compatibility.
>
> Actually, these are "bag" traits classes with three members:
>
> ::least
> ::fast
> ::exact
>
> I'll update the table to make this more explicit.

Yeah, I missed that.

> Many thanks, I've applied the other suggestions BTW - a big
> help - thanks!

You're welcome.

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