Boost logo

Boost :

From: Tim Peters (tim.one_at_[hidden])
Date: 2002-07-11 23:54:15

[David Abrahams]
> I recently came across a nasty configuration conflict between boost and
> python.
> In LongObject.h we have:
> /* Hopefully this is portable... */
> #ifndef ULONG_MAX
> #define ULONG_MAX 4294967295U
> #endif
> #ifndef LONGLONG_MAX
> #define LONGLONG_MAX 9223372036854775807LL
> #endif
> #define ULONGLONG_MAX 0xffffffffffffffffULL
> #endif
> Well, it turns out that boost detects whether the compiler supports long
> long by #including <limits.h> and looking for these macros:
> #include <limits.h>
> # if !defined(BOOST_MSVC) && !defined(__BORLANDC__) \
> && (defined(ULLONG_MAX) || defined(ULONG_LONG_MAX) ||
> defined(ULONGLONG_MAX))
> #endif
> So it turns out that on some platforms, Python's configuration sets
> HAVE_LONG_LONG even when limits.h doesn't include definitions of these
> macros.

Yes. Python cares about the conceptual type, not about how a platform
spells it.

> For example, there's MSVC6, where Python substitutes __int64 for
> long long using its LONG_LONG macro. However, I didn't actually notice
> the problem

What problem?

> until I tried linking something at LLNL where they're using an older KCC.
> Two translation units had different ideas of BOOST_HAS_LONG_LONG,

Why was that? Nothing you showed us for it, unless there's an implied
#include of Python.h before the Boost limits.h block you did show us.

> so linking failed when one of them was looking for the long long support
> supposedly provided by another. I'm surprised it wasn't a worse problem
> with MSVC6, because after all, it doesn't even supply a type called
> "long long".
> Is there any chance that something can be done to prevent this sort of
> conflict?

Rather than try to extract a clear question out of this <wink>, let me turn
it around: would your problem go away if this code in LongObject.h went
away entirely? Python has no business defining ULONG_MAX anymore (that's
left over from K&R C days), and I'm sure I got rid of all uses of
LONGLONG_MAX and ULONGLONG_MAX in 2.2 (I vaguely recall some; they weren't
really needed, and won't be needed again).

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