Boost logo

Boost :

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
> integer_traits both of which return min and max values. Now
> uses BOOST_STATIC_CONSTANT which will not work for compilers that do not
> support static inclass member initialisation, and for those that do,
> also need to support long long compile-time constants, which you say is
> 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
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at