On Wednesday, 14 November 2012 at 06:32:19 UTC, Jonathan M Davis
wrote:
The one cast that I'd be a bit concerned about would be casting
the floating
point value in deepHash to its representative bytes. I believe
that the cast
itself is okay, but I don't think that it's necessarily the
case that the same
floating point value will always have the same physical
representation.
I hope floating points are equal iff their byte representation is
exactly the same. If this is true then hash look up will return
false even for very small epsilon differences in value - but that
is the deal with floats.
At
minimum, NaN won't. So, it _might_ work with all normal
floating point numbers
(I'm not well enough versed in the exact layout of IEEE
floating point numbers
to be sure), but it _won't_ work with NaN. At minimum, you'll
have to special
case NaN if you want NaN to always result in the same hash. Of
course, if a
hash table were to use == as part of finding the key (I don't
think that the
built-in AAs currently do though), NaN would be pretty screwed
anyway (since
it would never be found even if it were there 50 times), so I
don't know how
big a deal it is. Better safe than sorry though.
Per this I am adding a special case for NaN in toHash. I already
have a special case for NaN in typesDeepEqual (and therefore ==).
Regarding the "copying structs with pointers" thread, your view
on 20/07/11 was:
"Maybe we actually need a copy constructor of some kind for this
sort of case.
I don't see how to get around it with a postblit. This is
definitely a big
problem."
With a generalized "dup" function for copying const(T) would you
agree this is not really an issue?
Thanks,
Dan
- Jonathan M Davis
