You are here:

C++/convert pointer to int


Could you please tell me how to convert a pointer to an integer. I am overloading delete and i want to convert a void * to a int.

First the standard blurb about avoiding doing such things:

In general you should not need to do such nastiness (although I concede that you may need to get into this sort of thing when writing memory allocators). Note that in general it is dangerous.

Consider for example what happens if you were to use such code on a system where sizeof(void*) > sizeof(int) (or for preference unsigned int).

Unlikely you think? Well I am using a system running Microsoft Windows Vista 64-bit, and the 64-bit memory model for this operating system (Win64) is that sizeof(int)==sizeof(long)==4 (32 bits) and sizeof(void*)==8 (64 bits), and yes I do have a 64-bit compiler for this system and do write code that builds for both 32-bit and 64-bit.

And earlier in the week I was following a thread on a mailing list in which someone remembered even weirder hardware in which integers and pointers were the same size, but pointers had the top bit set and integers did not and if you loaded the wrong one into the special registers that checked you would get a hardware trap.

So any code that relies on the size and representation of pointers and integers being compatible is going to be fragile and not portable, quite possibly even between related systems [e.g. between Win32 and Win64 systems, or 32-bit and 64-bit Linux distributions (where sizeof(void *)==sizeof(long)].

If I were you I would examine the reason you wish to do such a thing and see if you really need to do so - e.g. if it has to do with using a pointer as a key then could you use the pointer directly instead?

I would also not hardwire use of int (or unsigned int) into your code but rather use a type alias to a suitably sized integer for the system in question [in the case of Win64 it would be the currently non-standard (unsigned) long long for more recent Microsoft compilers - or (unsigned) __int64 for older ones].

Anyhow if you really must then use reinterpret_cast:

   intptr_t reinterpret_cast<intptr_t>(ptr);

The intent is that the intptr_t is a type alias (typedef) for an integer type suitable for holding the bits of a (non member) pointer. In fact intptr_t is a type alias from the C99 standard library (in the C99 header <stdint.h>).

C++ currently does not have such a useful set of aliases but they are in the current (optional) TR1 library extensions and therefore will be in the next C++ ISO standard in the header <cstdint> - the type aliases will of course be in the std namespace (or the std::tr1 namespace). Oh and the intptr_t is marked optional (presumably to allow for cases where there is no such integer type available).

If you do not have a standard library with TR1 support then such support can be found in the Boost libraries (, specifically, Boost support for other TR1 features can be located at

You can of course define your own type alias for such an integer type.

Note that while exactly what reinterpret_cast does is implementation defined the ISO C++ standard does state that:

      "A pointer can be explicitly converted to any integral type large enough to hold it.
       The mapping function is implementation defined
       [Note: it is intended to be unsurprising to those who know the addressing structure
       of the underlying machine. ]"

and that:

      "A value of integral type or enumeration type can be explicitly converted to a pointer.
       A pointer converted to an integer of sufficient size (if any such exists on the
       implementation) and back to the same pointer type will have its original value;
       mappings between pointers and integers are otherwise implementation defined."

Hope this helps.


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2017 All rights reserved.