Author: Uri Blass
Date: 09:51:53 02/08/04
Go up one level in this thread
On February 08, 2004 at 12:18:58, Dieter Buerssner wrote: >On February 08, 2004 at 10:29:19, Uri Blass wrote: > >>On February 08, 2004 at 09:59:37, Sune Fischer wrote: >>>You must do the cast before the operation, ie. if you do something like: >>> >>>int x=...,y=...; >>>__int64 f = x*y; >>> >>>it will not produce a __int64 result, similarly for a shift operation. >> >>Yes and I think that it is a mistake in defining the standard C behaviour. > >I disagree. It would be very difficult, to write efficient code in many cases, >then. I think that the default assumption should be that x*y is the mathematical result of x*y in case that it is possible(of course it is not possible if f=x*y when f is a 32 bit integer and x and y are 32 bit integers). I think that if a programmer likes to do it different then it should be mentioned and not the opposite and something like the following should be done. __int64 f= (int)(x*y) On some hardware/environments that multiplication cold take much longer >with your rule - even when the programmer really knew, that the multiplication >does not overflow in int arithmetics. If the programmers knows it and speed is important then the programmer should write it f=x*y when f is 32 bit number or __int64 f=(int)(x*y) when the compiler will know not to do the casting of x and y to 64 bit number thanks to the (int). I assume, the language creators thought >about this well. Also think at other examples: > >int x, y; >double f = x/y; > >Would you really want to do a floating point division here? > >How about f=x/y+0.5? I think that if you want an integer for x/y then it is better to have x div y in the syntex and not x/y. Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.