-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sean Kelly wrote: > Don Wrote: > >> Walter Bright wrote: >>> Don wrote: >>>> (This means that double y = int_val / 1; is OK, and also: >>>> double z = 90/3; would be OK. An alternative rule would be: >>>> "If an integer expression involves integer divison, that expression >>>> cannot be implicitly cast to a floating-point type"). >>> This is kinda complicated if one has, say: >>> >>> double z = x/y + 3; >> Integer expressions remain inexact until there's a cast. >> >> (It's very simple to implement, you just use the integer range code, >> adding an 'inexact' flag. Division sets the flag, casts clear the flag, >> everything else just propagates it if a unary operation, or ORs the two >> flags if a binary operation). > > Assuming it really is this easy, I'd love to see the change. I've run into > this bug countless times reviewing code, and it can be a tricky one to find. > I tend to be pretty particular about always appending the ".0" for literals > involved in floating-point assignments for this reason.
Ditto. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLJpLwT9LetA9XoXwRAmejAKCcoo9VMgotTyYugy+bLGjyr4iFKgCgvmSH l39YGMF98WLx5gaJ7HtcrZg= =FYgY -----END PGP SIGNATURE-----
