Re: [Boost-users] [integer] Request: long long (64 bits) support for int_t and uint_t

From: me22 (me22.ca_at_[hidden])
Date: 2007-06-06 11:57:07

On 06/06/07, Niels Dekker wrote:
> <stdint.h> is part of the C Standard already, and <cstdint> will be part
> of C++09.  So I don't expect to have much manual configuration work for
> new platforms...  Do you?
>
Given how well C99 has spread, I'd be worried about assuming too much
quick penetration for C++09.  9-bit bytes are still allowed by C++, if
not POSIX, and just using 8/16/32/64 doesn't get us any other things
that might be available.  Of course, I doubt anyone actually uses
boost on such machines anyways...

> Given the fact that <cstdint.hpp> is part of Boost already, it would
> make sense to me to allow easy access to its integer types by means of a
> templated struct like int_exact.
>
Agreed.

I'm wondering about a special thing like this:
template <size_t N, typename U = void>
struct stdint_t { typedef U type; }
template <typename U = void> struct stdint_t<32,U> { typedef int32_t type; }
// and etc

So that the current method could be combind with the stdint types.

> I think this is not a problem.  <boost/integer.hpp> requires template
> specialization as well.
>
Right, of course.  I thought too hard about one bit and forgot the other half :|

Suppose that we just went and used the cstdint.hpp method.  Would we then just
using uint_t<N> = uint_exact_t< ((N-1)|7)+1 >;
Since all the types we know about would be multiples of 8 bits?

> > How does the signed and  unsigned types together help you?
>
> I need to have signed and unsigned types of the same particular size.
> So I would like to do something like this:
>   typedef typename int_exact<sizeof(T)*8>::signed_type> my_types;
> Then I would use both my_types::signed_type and my_types::unsigned_type.
>
On the other hand, I suppose there might be value in making them
meta-functions, with just ::type (and maybe ::fast). int_fast_t should
probably also get a ::type, for metafunction usage. (Though I'm by no
means a qualified enough MPL wizard to know whether this would be at
all useful.)

Another option would be to go for stdint-style naming, and make
int_t<N>::type be the exact type, and add new int_least_t and
int_fast_t metafunctions.

And with C++09, you have
    using my_types<T> = int_exact_t<32,T>; // or whatever the syntax is
then my_type<signed>::type and my_type<unsigned>::type, so you can get
away without multiple typedefs in the same struct.

BTW: CHAR_BIT or integer_traits<unsigned char>::digits, not 8 :P

> BTW, a struct like get_unsigned<Integer> would be helpful to me as
> well.  Boost has such a struct implemented twice: in both
> <typeof/int_encoding.hpp> and <wave/util/flex_string.hpp>.  But
> unfortunately neither of them supports long long.  Also they both seem
> to be an undocumented implementation detail.
>
I went looking for a boost answer to
> That's a good question!  How many users would be affected by a drastic
> change of <boost/integer.hpp>?  And would the changes we're discussing
> increase the popularity of <boost/integer.hpp>?
>
And noticed a number of things like:
/usr/include/boost/xpressive/traits/cpp_regex_traits.hpp has
"define an unsigned integral typedef of the same size as std::ctype_base::mask"
So this does seem like a good suggestion.

Easy to implement, too:
template <typename T>
struct unsigned_ {
    BOOST_STATIC_ASSERT(integer_traits<T>::is_specialized);
// and maybe    BOOST_STATIC_ASSERT(integer_traits<T>::is_signed);
    typedef uint_exact_t<integer_traits<T>::digits+integer_traits<T>::is_signed>::type
type;
};
template <typename T>
unsigned_<T> make_unsigned(T x) { return unsigned_<T>(x); }

Or maybe a new metafunction,
int_size_as<T> = int_exact_t<sizeof(T)*CHAR_BIT>;

Since that's also the use I saw from google codesearch:
http://www.google.com/codesearch?q=%22%23include+%3Cboost%2Finteger.hpp%3E%22&hl=en&btnG=Search+Code
result: http://tinyurl.com/yqjphq

> It would be very nice to allow specifying signed/unsigned as a parameter
> argument indeed!  Specifying a 32-bits unsigned integer by int_t<32,
> unsigned>::exact, and a 64-bits signed integer by int_t<64,
> signed>::exact.  :-)
>
Having adjectives as types is fun, occasionally.  The wonders of
partial specialization :)

> FWIW, I find it acceptable to have int_t<31>::exact giving "void".
>
I agree.

~ Scott McMurray