Re: [boost] Re: Why no long long support in integer::int_t?

From: John Maddock (jm_at_[hidden])
Date: 2002-09-04 06:01:20

> > Also, one of the concerns brought up the last time this suggestion was
> > given was that a compiler may supply extended-long type(s), but not
> > allow them to be used as compile-time constants in value-based template
> > parameters.  The CRC library uses this library in this manner.
> Yikes, now this is an issue.  Integer.hpp uses both std::numeric_limits
and
> integer_traits both of which return min and max values.  Now
integer_traits
> uses BOOST_STATIC_CONSTANT which will not work for compilers that do not
> support static inclass member initialisation, and for those that do,
they'll
> also need to support long long compile-time constants, which you say is
not
> all.  However std::numeric_limits implements min and max functions which
> persumably would work.  If I could specialise std::numeric_limits<int64_t>
> and std::numeric_limits<uint64_t> if they were not done so by the builtin
> limits.h I think I can get this to work.  However where would I place the
> specialisations?  boost/limits.hpp seems the obvious place to start but it
> is currently so clean I'd hate to start filling it up with compiler config
> stuff.  I could put it in Integer.hpp, but that just seems plain wrong as
it
> is now dislocate from the rest.  Any ideas?

Two points:

<boost/limits.hpp> already contains fixes for std libs that have 64-bit
ints, but no numeric_limits specialisations.

The macro BOOST_NO_INTEGRAL_INT64_T can be used to check whether 64-bit ints
can be used in integral constant expressions.

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm