Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-16 08:10:33

Gennaro Prota <gennaro_prota_at_[hidden]> writes:

> On Sat, 15 Feb 2003 12:00:36 -0000, "John Maddock"
> <jm_at_[hidden]> wrote:
>>> Can't we detect
>>> whether the compiler is supporting "long long" and only enable the
>>> long long code under those circumstances? In fact, /don't/ we do
>>> that?
>>> If this is just about inconvenient warnings, it seems to me that
>>> telling people "disable long long support or disable the warning" is a
>>> perfectly sensible approach.
>>> What am I missing?
>>I agree completely: the issue is that older EDG compilers (prior to 3.0.0)
>>don't signal whether they're in strict mode or not
> Well, it's unfair to offload it on the compilers though. They aren't
> certainly obliged to tell you that a non standard type is not
> available.

No they are not, but IIUC we don't default to assuming that it is
available. We only decide that it's available if the compiler
explicitly tells us so.

> But I'm getting tired of all this discussion, I'm just replying for
> the equity's sake. Just to set records straight: the problem was not
> compilers; it's just that one should IMHO be able to compile, let's
> say, boost::is_integral in strict mode, unless she does use
> is_integral<long long>.

And you can't do that today?

> If I just use is_integral<int>, why should I get errors?

You should not.

> As you know (see
> ) __NO_LONG_LONG is just a 3.0 addition. There's a whole world of EDG
> front ends that don't have it, and there's a whole world of EDG users
> who want to compile in strict mode. BTW, Dave asked "can't we detect
> whether the compiler is supporting long long?". Can we?

I'd still like to know. In the cases where we can't detect that long
long is unavailable, I agree with Gennaro that we should not assume it
will be available. People use EDG compilers especially to check
conformance, and so are especially likely to run in strict mode.

Dave Abrahams
Boost Consulting

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