Nonportable code in C++ support

[Kuba Ober]

On Wednesday 13 February 2008, Esben Mose Hansen wrote:
> On Wednesday 13 February 2008 17:13:16 Kuba Ober wrote:
> > On Wednesday 13 February 2008, Kris Wong wrote:
> > > > But since the hash-values are always 32 bit, won"t you then
> > > > get a warning when
> > > > casting long -> uint? :) Of course, any way of removing the
> > > > warning is fine.
> > >
> > > int hash = (int)((size_t)ptr + [whatever]);
> > >
> > > Let's not forget, longs are 4 bytes on 64 bit Windows.
> >
> > Wouldn't this work better? It should be portable, too, although
> > it has a benign warning on 32 bits.
> >
> > void * ptr;
> > unsigned long lptr = (unsigned long)ptr;
> > lptr = (lptr >> 32) ^ (lptr & 0xffffffff);
> > int hash = (int)lptr;
> >
> > The hash value on 32 bit platforms should be simply the value of the
> > pointer, while on 64 bits it will be the upper and lower halves xor-ed
> > together.
>
> You mean, in the case you get many hash collisions across 4Gb of memory?

I don't know how the memory is organized on 64 bit machines, but presumably 
they have virtual memory too, and one then presumes that say stack, heap and 
dynamic libraries can be possibly spread all over the petabytes. Just like on 
some 32 bit platforms - heap, stack and library code are nowhere near one 
another, there are huge address holes between them.

I wouldn't call it a big coincidence if the address of some constant allocated 
in the constant data area had the same last 32 bits as something from the 
heap, for example.

And 4Gb+ heaps are really nothing unheard of in more and more workstation 
environments. I run an application which has about 2Gb of heap allocated at 
any given time. On larger problem sets I envision it will easily have triple 
that amount. If this application code, which is really a library in a small 
executable wrapper, was linked into say a KDE application which used the code 
in question, it'd break.

Cheers, Kuba