On 9/26/05 10:49 AM, "Joaquín Mª López Muñoz" <joaquin@tid.es> wrote:
Martin Bonner ha escrito:
----Original Message---- From: Joaquin M Lopez Munoz [mailto:joaquin@tid.es]
Is BOOST_HAS_INTPTR_TYPES supposed to inform whether there are vendor-provided ::intrptr_t/::uintrptr_t types? If so, I fail to see its utility, since boost::intrptr_t/boost::untrptr_t can be provided universally.
Not if the compiler doesn't HAVE a integral type which can hold a pointer. For example, a compiler for Intel processors with 32 bit longs, no long long, and 16:32 pointers.
But then, one doesn't really care whether the vendor has ::[u]intrptr_t as long as she has Boost-provided boost::[u]intrptr_t, right? To cope with the situtations you describe, the macro should be named then something like BOOST_NO_BOOST_INTPTR_TYPES or BOOST_NO_POINTER_SIZED_INT_TYPE or anything that makes it clear we are refererring to boost/cstdint.hpp rather than the vendor stuff.
You assuming that Martin's scenario is caused by the compiler maker being unwilling to map a pointer type to an integral type. The actual point was that the compiler maker may be UNABLE to create a mapping. In other words, we (i.e. Boost) can't make the typedef-s either! (Unless you're so slick you can make a mapping even if "sizeof( void * ) > sizeof( [u]intmax_t )".)
Besides, from what Beman says seems there's no current Boost-supported platform where boost::[u]intrptr_t couldn't be assigned a suitable type.
There's no guarantee that a later supported platform (either old or new) would have a compatible integral type. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com