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

On 06/06/07, Niels Dekker wrote:

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 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 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. 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::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 and . 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 ? And would the changes we're discussing increase the popularity of ?

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