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