From: Niels Dekker - mail address until 2007-11-30 (nd_mail_address_valid_until_2007-11-30_at_[hidden])
Date: 2007-06-06 05:34:47
>> Why not having int_exact_t entirely based on the exact-width integer
>> types from <boost/cstdint.hpp>?
me22 wrote:
> The current implementation works in an entirely standard manner, which
> I consider an advantage.
>
> cstdint.hpp, on the other hand, consists solely of by-hand listings of
> using declarations and typedefs that require manual configuration work
> for new platforms.
<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 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.
>> Actually I was thinking of a far more simple implementation, as
>> follows. (In practice, I find it quite convenient to have the signed
>> and the unsigned type grouped within one struct.)
>>
>> ////////////////////////////////////////////////////////////
>> template <unsigned Bits> struct int_exact
>> {
>> };
...
>> template <> struct int_exact<32>
>> {
>> typedef int32_t signed_type;
>> typedef uint32_t unsigned_type;
>> };
>>
>> #ifndef BOOST_NO_INT64_T
>> template <> struct int_exact<64>
>> {
>> typedef int64_t signed_type;
>> typedef uint64_t unsigned_type;
>> };
>> #endif
>> ////////////////////////////////////////////////////////////
> I'm not sure if that is actually simpler, as it requires template
> specialization, which has historically been avoided where possible,
> for compatibility. I think the problem platforms are being dropped in
> 1.35, however, so this may no longer be a problem.
I think this is not a problem. <boost/integer.hpp> requires template
specialization as well. But it surely isn't as simple as my struct :-)
> 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.
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.
> If we're going all-out on interface, allowing specializations and
> stuff, there are a number of other possibilities. One fun one that's
> even backwards compatible is still allowing int_t<25>::least and
> uint_t<25>::least, but also int_t<25,unsigned>::least (and
> int_t<32,signed>::least).
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. :-)
> The reason I didn't consolidate ::exact into int_t and uint_t
> originally was that it makes it annoying (or maybe impossible) to
> preserve the non-existence semantics for the ::exact typedef when such
> a type is unavailable. Making it give void is easy and does almost
> all the same things, but then you don't get an error from typedef
> int_t<31>::exact myint; at typedef definition, only when the typedef
> is actually used.
FWIW, I find it acceptable to have int_t<31>::exact giving "void".
> Of course, I have no idea where (whether?) anyone uses boost/integer.hpp...
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>?
Kind regards,
-- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center