Re: [boost] BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-30 11:17:18

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

> On 1/30/02 3:32 AM, "David Abrahams" <david.abrahams_at_[hidden]> wrote:
>
> > 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).
>
> That makes sense. We can think of it as a feature of <boost/limits.hpp>.
> It's too bad, because this introduces the first difference between
> <boost/limits.hpp> and a standard-conforming <limits>, other than the file
> name.
>
> You'll have to pardon me for suggesting the name
> BOOST_LIMITS_NO_COMPILE_TIME_CONSTANTS. While the name does make logical
> sense, it's no-doubt a terrible choice because it's so similar to the
other
> one.
>
> 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.

-Dave