Boost logo

Boost :

From: Chris Little (cslittle_at_[hidden])
Date: 2002-03-19 22:09:24


I have been looking at Jeff Garland's Gregorian Date/Time Library and I am
having difficult using it with Metrowerks CWP 7.2.

I have had an email discussion with Jeff and he has fixed the minor issues
but the final sticking point is how boost/cstdint.hpp interacts with the
cstdint provided by Metrowerks.

Currently boost/cstdint.hpp is structured to act like two header files in
one.

The first block defines the C numeric types (by including stdint.h or direct
definition) and then imports the types into the boost namespace.

The second block defines INTn_C, UINTn_C, ... if requested and the compiler
doesn't provide support natively.

My problem arises because Metrowerks is configured to provide all of the
support. I.e. That boost/cstdint.h really only includes stdint.h which
includes cstdint and then imports the types into the boost namespace.

If I have a header files that has

#include <boost/cstdint.hpp>

And later in another header file I have

#define __STDC_CONSTANT_MACROS
#include <boost/cstdint.hpp>

The INTn_C macros are not defined because the include of stdint.h inside
boost/cstdint.hpp is inside the include guards for the first block.

For platforms that do not provide the INTn_C macros the boost model works
fine because of the two blocks inside the single header file.

I'm not sure how to fix this. I'm thinking that what I need is a new config
flag like BOOST_HAS_CONFORMING_CSTDINT and that boost/cstdint.hpp would look
something like

#include <boost/config.hpp>
#if BOOST_HAS_NATIVE_CSTDINT

#include <cstdint>
#include <climits>

Namespace boost
{
Import types
}

#else

... Existing boost/cstdint.hpp ...

#endif

Notice the lack of include guards around the whole file because we need to
force cstdint to be included each time because someone may have defined
__STDC_CONSTANT_MACROS be including boost/cstdint.hpp.

Does anyone have a better suggestion before I submit a patch?

Chris


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk