[Issue 8530] Float types default initializers doesn't work in class

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Aug 15 08:09:26 PDT 2012


http://d.puremagic.com/issues/show_bug.cgi?id=8530


Iain Buclaw <ibuclaw at ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw at ubuntu.com


--- Comment #5 from Iain Buclaw <ibuclaw at ubuntu.com> 2012-08-15 08:09:25 PDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > If you want to check for NaN, then use std.math.isNaN. As I understand it,
> > > > there is no guarantee that two NaN values have the same bit pattern (at
> > > > minimum, you have signed and unsigned NaN, and there may be more variations - I
> > > > don't remember). isNaN returns true in both cases. So, I don't believe that
> > > > this is a bug.
> > > 
> > > Thanks for your reply. However I still think it is a bug, because when I assign
> > > TYPE.init to variable VAR of type TYPE, and then I compare VAR is TYPE.init, I
> > > assumed it returns true;
> > 
> > Your assumption is not correct. If type.init is a signalling NaN, the bit
> > pattern changes when you access it. It has nothing to do with classes.
> > 
> > More generally,
> > 
> > x = y;
> > assert (x is y);
> > 
> > Fails if x is floating point and y is a signalling NaN.
> > When reading from x, the 'quiet' bit of will be set, so that it reads a quiet
> > NaN, not a signalling one.
> > That's the way the hardware works, the same behaviour applies in any language
> > that uses the hardware.
> 
> OK, but still I dont understand why others compilers(LDC,GDC) works as I expect
> and why real type in DMD behave different.


GDC calls memcmp() between the two floating values - dunno what DMD does...

Regards
Iain

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list