Re: [boost] [cstdint] uintptr_t and intptr_t are missing

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