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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk