On Mon, 19 Sep 2005 01:29:36 +0400, Beman Dawes <bdawes@acm.org> wrote:

"Maxim Yegorushkin" <maxim.yegorushkin@gmail.com> wrote in message news:op.sxa6eylkp2vbb7@home...

...

Is this intentional that uintptr_t and intptr_t types are missing in cstdint.hpp? If it is so, why?

http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html

An oversight? Care to submit a patch?

Here is a patch. I checked it with BOOST_CSTDINT_HPP macro set and not set with Fedore Core 4 on x86-32. A patch and a check for __FreeBSD__ is still needed.

Beman Dawes <bdawes <at> acm.org> writes:

I spoke too soon. The reason intptr_t and uintptr_t were omitted was because they are not required by C99, and hence not required by TR1.

So we should discuss this further before applying Maxim's patch.

On one hand, we may not want Boost code to use a feature that may not be present.

OTOH, if virtually all modern C++ compilers do support an integral type large enough to hold a pointer, why not supply intptr_t and uintptr_t?

I second this option. I know I'll be needing this facility in the near future, and probably other libs can take advantage of it as well (pointer hashing in Boost.Hash, for instance.)

One possibility is to go ahead and supply intptr_t and uintptr_t, and also supply a BOOST_HAS_INTPTR_TYPES (or perhaps BOOST_NO_INTPTR_TYPES) configuration macro.

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. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo