Re: [boost] boost/cstdint.hpp definition of INTMAX_C conflicts with MPFR

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.