Re: Nonportable code in C++ support

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;

I hate to say it, but this is one place I'd advocate the use
of '#if 
PTR_SIZE > 4'...

>> 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? 
> Personally, I'd go with the code from the c++ standard
library:
> 
> return reinterpret_cast<std::size_t>(p);
> 
> except that the cast would be to int  Simple,
fast, and very likely to 
> return different values for different pointers, even
modulo some number 
> 2^n-1.

I won't quote Kuba Ober, but to an extent I think he has a
point (but 
that said, is a single hash-value collision here or there
really so bad, 
so long as things are generally well-spread-out?). What I'd
like to 
know, however, is why no one has mentioned the fact that a:
malloc'd 
data is aligned to not less than PTR_SIZE bytes, and b: in
general, the 
chances of having pointers stacked against each other is not
very high 
(IOW, unless you're inserting pointers to consecutive
entries in an 
array of small elements, you won't have pointers that differ
by less 
than some modest amount).

In other words, stripping 2-4 bits off the bottom of the
pointer to make 
the hash would seem like a sensible thing to do.

-- 
Matthew
Thus sang the fat lady...


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel