Re: [boost] BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-30 06:32:05

----- Original Message -----
From: "Darin Adler" <darin_at_[hidden]>
To: "Boost" <boost_at_[hidden]>
Sent: Wednesday, January 30, 2002 2:11 AM
Subject: Re: [boost] BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS

> On 1/29/02 7:45 PM, "David Abrahams" <david.abrahams_at_[hidden]> wrote:
>
> > How should the BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS macro interact
with
> > boost/limits.hpp?
> >
> > In order to suppress warnings generated by numeric_cast with MinGW, I
had to
> > change checks to:
> >
> > #if !defined(BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS) ||
> > defined(BOOST_SGI_CPP_LIMITS)
> >
> > ...which looks at the #include guard for boost/limits (ick). I think it
> > would be a mistake to turn off BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
inside
> > limits.hpp because of ODR implications. Maybe we need another macro that
> > says whether we have the constants after including boost/limits.hpp?
>
> My preference would be to have <boost/limits.hpp> change the state of
> BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS to reflect the change in status. If
> <boost/limits.hpp> defines compile time constant versions of the limits,
> then it can #undef BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS.
>
> Any reason not to do this?

I'm worried about ODR violations: in one translation-unit, an implementation
choice might get made based on the state of the macro, while the other TU
includes boost/limits.hpp and so gets a different implmentation of the same
code. Since we can't force people to use boost/limits.hpp, we probabaly
ought to define a macro which says whether boost/limits.hpp gives you
compile-time constants (or change the meaning of the existing macro).

-Dave