[dmd-beta] Struct Comparision WTF: Is the new or old behavior right?

[kenji hara]

You can use s is S.init for bitwise comparison.
2011/12/10 17:02 "Jonathan M Davis" <jmdavisProg at gmx.com>:

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