On Monday, November 11, 2002, at 8:59 AM, Kevin S. Van Horn wrote:
I have found that
boost::uint_t<64>::fast
gives a compiler error even on a platform (RH 7.3 on Intel) that has
64-bit integers available (as long long). On checking the
documentation
again, it does specify this behavior, but this strikes me as quite
unreasonable; if a platform has long long, I should be able to use it.
The reason it hasn't been added is that there is no guarantee that long
long constants can be used at compile-time (since it's not officially
part of C++).
I believe that all that is needed to fix this is inclusion of the
following lines:
#ifdef BOOST_HAS_LONG_LONG
template <> struct int_least_helper<0>
{ typedef long long least; };
#endif
#ifdef BOOST_HAS_LONG_LONG
template <> struct int_least_helper<5>
{ typedef unsigned long long least; };
#endif
The cases for 0 and 5 are left out deliberately so desired bit counts
beyond any integer type give an error. So a "fix" for this would have
to _add_ two new cases, still leave two error cases, and work when a
compiler doesn't have long long.
Also, I'd like to see the following added to <boost/integer.hpp>:
boost::signed_int<T>::type -- Gives the signed integer type of the
same
size as integer type T.
boost::unsigned_int<T>::type -- Gives the unsigned integer type of the
same size as integer type T.
Rationale: I often find myself using
std::iterator_traits<Iterator>::difference_type
for quantities that are guaranteed to be nonnegative; for these I would
prefer to use an unsigned type.
Got a sample implementation? I could think of
template < typename T >
struct unsigned_int
{
typedef uint_t<sizeof(T) * CHAR_BIT> type;
};
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
