www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - postblit, const(T) copy, dealing with structs

reply "Dan" <dbdavidson yahoo.com> writes:
I've been trying to wrap my mind around D and come up with my own 
philosophies for how to use it best. I've been getting many 
questions answered on the *learn* forum. I wanted to present some 
thoughts here in the hopes that if the ideas and approaches are 
glaringly wrong the experts will let me know pretty quickly.

For instance, I have my own take on how to address this issue 
discussed here.

http://www.digitalmars.com/d/archives/digitalmars/D/Copying_structs_with_pointers_140951.html
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Confused_about_const_19185.html

Unfortunately, it does not come about until page 18. But 
hopefully some will take the time to read what I have produced 
and set me straight. :-)

The document is at: 
https://github.com/patefacio/d-help/blob/master/doc/canonical.pdf

I'm particularly interested in knowing if my handful of casts in 
this code are as safe as I hope.
https://github.com/patefacio/d-help/blob/master/d-help/opmix/mix.d


Thanks
Dan
Nov 13 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, November 13, 2012 21:40:57 Dan wrote:
 I'm particularly interested in knowing if my handful of casts in
 this code are as safe as I hope.
 https://github.com/patefacio/d-help/blob/master/d-help/opmix/mix.d

Glancing over them, I don't see any major problems. Casting to immutable is safe as long as there are no other mutable references to the data, and casting away const is safe as long as you don't mutate anything after casting const away (though ideally you still wouldn't be casting away const). 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. 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. - Jonathan M Davis
Nov 13 2012
prev sibling parent "Dan" <dbdavidson yahoo.com> writes:
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

Nov 14 2012