> > I'd have thought the "easy" case for the compiler is just > to treat all > > these implicit double-to-float conversions as worthy of comment, but > > here it is clearly only warning about the case where there > will be some > > (additional) loss of precision. > > Ian, there was _no_ loss of precision in cases 0.5, 0.25. Because > these numbers can be represented as exact values even in single float > format.
Yes - that's what I said. The 0.1 case is the only one where there is an inexact representation, and therefore the only one that suffers from a loss of precision when cast from double to float. The other values are exact whether represented as doubles or as floats. But, my interpretation (possibly wrongly) of the (unqualified) value 0.5 is that the compiler should treat it as a double, whereas 0.5f is a float. So all the values are being implicitly cast from double to float by the compiler. Regardless of the fact that there is no loss associated with the cast, it just seemed odd to me that the compiler did not bother to mention it... I imagined that it would, but clearly it is not flagging up the cases where there is "no harm done". That was not what I expected. It seemed odd to me, which is why I commented. It *still* seems odd to me... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
