From: Daryle Walker (darylew_at_[hidden])
Date: 2005-09-29 07:55:36
On 9/26/05 10:49 AM, "Joaquín Mª López Muñoz" <joaquin_at_[hidden]> wrote:
> Martin Bonner ha escrito:
>> ----Original Message----
>> From: Joaquin M Lopez Munoz [mailto:joaquin_at_[hidden]]
>>> 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
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk