postblit, const(T) copy, dealing with structs

[Dan]

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