Boost logo

Boost :

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2002-03-30 09:40:31

David Abrahams wrote:
> > I think it's a great idea for <boost/limits.hpp> to export a macro which
> > communicates this.
> Do we really care about whether the native <limits> header provides
> compile-time constants? I think we can just change the meaning of the
> existing name, since boost/limits.hpp will include the native one if it
> exists. The only difference here is that if you want to use the macro, you
> have to #include <boost/limits.hpp>. Simple.

So the root of the problem is that, under certain circumstances,
are both defined. The former causes <boost/limits.hpp> to define
a std::numeric_limits<> template which does have compile-time constants,
so, strictly speaking, the BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS is
wrong from then on.

I believe the following section from config/suffix.hpp does not
reflect the existence of <boost/limits.hpp>:

// If there is no numeric_limits template, then it can't have any compile time
// constants either!
# if defined(BOOST_NO_LIMITS) \
# endif

I've removed that section and I've made sure that
config/stdlib/sgi.hpp undefines the "no-constants' when it
defines the BOOST_NO_LIMITS macro. (That's the only place
where BOOST_NO_LIMITS is defined.) Everyone should
use #include <boost/limits.hpp> when looking for std::numeric_limits
anyway. I've fixed the only places where this wasn't true
in boost/detail/numeric_traits.hpp and boost/counting_iterator.hpp.

The config documentation has been augmented to indicate that BOOST_NO_LIMITS
should never be used in client library code, but <boost/limits.hpp>
in all cases.

I hope this addresses all the issues.

(Btw, John, my name is "Jens", without apostrophe. :-) )

Jens Maurer

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