Nonportable code in C++ support

[Esben Mose Hansen]

On Thursday February 14 2008 14:30:07 Kuba Ober wrote:

> 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.

Sure, it is possible, for the case where someone stores pointers to objects on 
the stack in a hash. But it doesn't really change much.

>
> 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.

It could happen, but it is just a hash collision. Which means, it is a 
performance penalty *only*, and on average it should be much smaller than 
doing bit shifting on every single hash lookup.

>
> 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.

It wouldn't break. It's a hash function, it's going to get moduloed with some 
smallish number anyway. The hash function just need a reasonable chance to 
get different results for different pointers, fast. The latter is the reason 
why I wouldn't bitshift it with size_t, even though those bits would likely 
nearly always be zero.

(And now I promise to shut up. I just couldn't let the "it'd break" pass :) )

-- 
regards, Esben