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

Subject: [boost] boost/cstdint.hpp definition of INTMAX_C conflicts with MPFR
From: Vincent Lefevre (vincent_at_[hidden])
Date: 2010-02-15 09:04:58

Hi,

I'm a MPFR developer and the following problem with Boost has been
reported in the MPFR mailing-list.

As of Boost 1.42, the macros INTMAX_C and UINTMAX_C (in particular)
are always defined, and on a system without <stdint.h> (Microsoft C++
compiler), the build of a program using Boost 1.42 and MPFR failed.

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).

Even though one could specify a macro for MPFR that would allow the
user to disable (u)intmax_t support explicitly, I think that Boost's
behavior is rather awkward, and may break other software too (in
particular libraries that would do the same kind of things as Boost).
Indeed (correct me if I'm wrong, I don't know very much about C++),
while types have namespaces, macros don't, but there are conventions
under which using a prefix such as BOOST_ can be used in place of a
namespace (to avoid conflicts with other software).

So, I wonder why Boost doesn't do the following: since it defines the
intmax_t and uintmax_t types in the boost namespace, it should use
the BOOST_ prefix for the corresponding macros, e.g. BOOST_INTMAX_C
and BOOST_UINTMAX_C. The only acceptable artifact concerning these
types would be that additional types and macros be defined due to the
inclusion of standard headers such as <stdint.h>; but in such a case,
the behavior would remain consistent (i.e. INTMAX_C and UINTMAX_C
would be defined only if intmax_t and uintmax_t are available).

If, for some reason, Boost really needs to define the INTMAX_C and
UINTMAX_C macros, then it should also define intmax_t and uintmax_t
in the global namespace. But I don't think that's a good idea.

Regards,

-- 
Vincent Lefèvre <vincent_at_[hidden]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)