<p>You can use s is S.init for bitwise comparison.</p>
<div class="gmail_quote">2011/12/10 17:02 "Jonathan M Davis" <<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Friday, December 09, 2011 23:56:30 Walter Bright wrote:<br>
> On 12/9/2011 10:36 PM, David Simcha wrote:<br>
> > Using DMD 2.057 beta:<br>
> ><br>
> > // test2.d:<br>
> > import std.stdio;<br>
> ><br>
> > struct S {<br>
> ><br>
> >     double d;  // NaN<br>
> ><br>
> > }<br>
> ><br>
> > void main() {<br>
> ><br>
> >     S s;<br>
> >     writeln(s == S.init);<br>
> ><br>
> > }<br>
> ><br>
> > $ dmd test2.d -m32<br>
> > $ ./test2<br>
> > true<br>
> > $ dmd test2.d -m64<br>
> > $ ./test2<br>
> > false<br>
> ><br>
> > Somehow I think it's a bad idea to have the result of this comparison<br>
> > change depending on whether you're compiling in 32- or 64-bit mode.  I<br>
> > just spent a few hours debugging Plot2kill because this behavior<br>
> > changed between releases in 64-bit mode, and I was comparing font<br>
> > structs to their .init values to determine whether they had already<br>
> > been initialized.  Everything worked in 32-bit mode but failed in<br>
> > 64-bit mode.  In 64-bit mode it looked like the structs had already<br>
> > been initialized (e.g. titleFont == Font.init is false) so they never<br>
> > got initialized.  Needless to say, GTK does weird things when you pass<br>
> > in a NaN as a font size.<br>
><br>
> The 32 bit code is wrong (please file a bug report). Comparisons should<br>
> always yield false if one or both operands is a nan.<br>
<br>
That makes it kind of ugly for init though, since it's often useful to check<br>
whether a value is equal to its type's init value. Treating NaN like this<br>
means that you can't do such equality checks if your type includes any floating<br>
point values - directly or indirectly. But it _would_ break the normal<br>
behavior of NaN to make init values act differently (and likely complicate the<br>
code generation a fair bit, since it would mean special casing init with<br>
regards to equality). So, I guess that it just means that you have to be<br>
careful when dealing with default-initialized floating point values.<br>
<br>
Part of me thinks that NaN should be equal to NaN, but it's likely too late<br>
for that at this point, even if it were determined to be a good idea.<br>
<br>
In any case, it's a bit funny to see a code generation error which is correct<br>
in 64-bit mode and incorrect in 32-bit mode. That's the reverse of what<br>
normally happens.<br>
<br>
- Jonathan M Davis<br>
_______________________________________________<br>
dmd-beta mailing list<br>
<a href="mailto:dmd-beta@puremagic.com">dmd-beta@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/dmd-beta" target="_blank">http://lists.puremagic.com/mailman/listinfo/dmd-beta</a><br>
</blockquote></div>