Subject: Re: [boost] boost/cstdint.hpp definition of INTMAX_C conflicts with MPFR
From: John Maddock (john_at_[hidden])
Date: 2010-02-15 12:17:57
>The reason is that mpfr.h supports systems with and without intmax_t
>(so that it does not force <stdint.h> inclusion), thus it must have
>a way to determine when intmax_t is available, without requiring the
>user to do anything else than including <stdint.h> first. So, it has
>several heuristics, one of them being the test of the existence of
>INTMAX_C and UINTMAX_C. Indeed, in C, which does not have namespaces,
>it is rather intuitive that the existence of INTMAX_C and UINTMAX_C
>implies that the corresponding types intmax_t and uintmax_t are
>available. However, in C++ with Boost, intmax_t and uintmax_t are
>not necessarily available (in the global namespace).
Hmm, how can you use INTMAX_C to check for the existance of stdint.h when
INTMAX_C is *defined in stdint.h*. Note also that historically C++ systems
have not defined INTMAX_C when including stdint.h (or any other header)
unless a specific "magic macro" is defined (__STDC_CONSTANT_MACROS).
Which brings us on to C++0x and the next C++ std. In there INTMAX_C is
always defined after including <cstdint>, but there is no intmax_t in global
namespace (only namespace std) - it's this behaviour that Boost's stdint.hpp
is trying to emulate. We're also not alone in this - for example ICU will
define some of the INT#_C macros if they're not already supplied. And
finally... the behaviour was introduced in response to user requests/bug
reports, so I don't think we'll change, sorry!
BTW Doesn't mpfr already use an autoconf script for configuration? If so
isn't it trivial to check for that header in that?
HTH, John.