Re: 64 bit C++ and OS defined types
On May 2, 3:59 pm, "Bo Persson" <b...@gmb.dk> wrote:
peter koch wrote:
[...]
I am not sure that there is such a wide demand, but there
are legitimate reasons that one might want to look at
pointeres as ints that might creep up into many types of of
programming. One such frequent one could be for hashing,
other one could be related to special memory allocators.
Agreed, but there is not much use for a general preprocessor
define here, as hashing would also need to things like how
many bits are actually used (48 out of 64?). The same for a
memory alllocator.
Not only how many bits, but how they are used. On segmented
architectures (IBM mainframes, Intel 16 and 32 bit processors),
you also run the risk that the results of converting to an
integer may result in different values, even when the pointers
compare equal.
For most RISC architectures (and many others: AMD/Intel 64 bits,
and Intel when compiled in small model, where only the offset is
relevant, and in some modes on a modern IBM mainframe), the
obvious solution is just to treat the pointer as an array of
unsigned char, e.g.:
unsigned
hashPtr( void* ptr )
{
unsigned result = 2166136261U ;
unsigned char* current
= reinterpret_cast< unsigned char* >( &ptr ) ;
unsigned char* end = current + sizeof( void* ) ;
while ( current != end ) {
result = 127U * result + *current ;
++ current ;
}
return result ;
}
I don't think I'd consider that "looking at a pointer as an
int".
You could just use int, or unsigned long long, or perhaps
ptrdiff_t, as appropriate for a specific system. You must know
the target system anyway.
On some of the systems I've worked on, the "appropriate" type
would be a struct.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34