Re: [boost] [cstdint] uintptr_t and intptr_t are missing
----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. -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
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. 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. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
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
Daryle Walker ha escrito:
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 )".)
I think I failed to express myself. In fact, I agree with you. Let's see, a vendor may not provide ::[u]intrptr_t for the following reasons: a) they didn't bother to do it (as this is not mandated by the C++ std anway) b) it can't be done, because there's no such integral type. So, what I propose is that boost::[u]intrptr_t is provided whenever possible (regardless of the vendor's headers) and that the macro BOOST_NO_POINTER_SIZED_INT_TYPE refers only to situation b). AFAICS this also reflects your position, doesn't it? Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (3)
-
Daryle Walker -
Joaquín Mª López Muñoz -
Martin Bonner