Author: Robert Hyatt
Date: 07:01:14 07/04/02
Go up one level in this thread
On July 04, 2002 at 04:14:00, Sune Fischer wrote: >On July 03, 2002 at 21:21:05, Robert Hyatt wrote: > >>On July 03, 2002 at 17:57:37, Sune Fischer wrote: >> >>>On July 03, 2002 at 17:00:49, Robert Hyatt wrote: >>> >>>>On July 03, 2002 at 16:09:37, Sune Fischer wrote: >>>> >>>>>Hi quick question. >>>>> >>>>>// this one is "faulty": >>>>>#define RANK64(r) (0x00000000000000FF<<(r<<3)) // r is 0-7 >>>>> >>>> >>>>That long number is _not_ a 64 bit value. If you cast the hex constant >>>>to 64 bits, the shift amount doesn't need to be cast (and it might well be >>>>more efficient that way as well). >>> >>>Then it has to be because of the leading zeros, because usually it _is_ a 64 bit >>>number. The same trick on the file worked great, but that number is >>>0x0101010101010101, which is then correctly read as a 64 bit type. >>> >>>-S. >> >> >>That is the problem. ie 0x000000000000000000000000000000000000001 is still a >>small number. Leading zeros get ignored... > >Yes, but IMO the compiler should give a warning here, there is no long long long >long type :) > >I'm curious, is 0xff then used as an 4 byte integer and not as a char? >So I might as well use 0xf instead of 0x0f or 0x0000000f, its all the same to >the compiler? > >-S. I really don't know, but I suspect 0xff is "typeless" and the compiler is at liberty to store it however it wants. I would assume it would use the native word-size as the default. IE on an alpha, you would get your 64 bit value, on a 286 it would probably be a 16 bit value, etc...
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.