Author: James Swafford
Date: 14:41:03 01/17/06
Go up one level in this thread
On January 17, 2006 at 14:59:15, Robert Hyatt wrote: >On January 17, 2006 at 12:52:40, James Swafford wrote: > >>On January 17, 2006 at 12:29:21, JW de Kort wrote: >> >>>Thank you for your reply. I check the boundries of the array's but that seems to >>>be correct. >>> >>>Could you please clarify your response because i'am not 100% sure what you mean. >>> >> >>I'll try. Let me preface this with this caveat: I doubt this is >>your problem. :) Dann's advice is pretty sound. >> >>Let's say you are evaluating a bitwise expression "a & b". >>If a == 0, then ( a & b ) == 0 for any b. So, it's not >>necessary for the compiler to go to the trouble of figuring >>out what b is. >> >>In your case, a & b represent items in an array. What is >>really evaluated is probably implementation specific >>(depends on the compiler), but it wouldn't even need to fetch >>the item from the second array to do the bitwise comparison >>if your first item (a) is 0. So, possibly you are skirting a >>boundary bug when i==1 since your "a" is always 0. >> >>Again, I doubt that's the case in your program, but it's >>a possiblity. >> >>-- >>James >> > >I don't see how that would cause a problem, since it has to fetch both values, >and then AND them to produce the final zero/non-zero result for testing. This >isn't the same as Why does it have to? If you say that's what most compilers *do*, then I believe you (I don't claim to be a compiler expert), but, mathematically, they don't *have to*, since 0 & b == 0 for any integer b. Please tell me what I'm missing. :) -- James > >if (a && b) where if a is 0, b would not even be fetched usually... > >> >> >>> >>>On January 17, 2006 at 11:54:29, James Swafford wrote: >>> >>>>On January 17, 2006 at 11:27:35, James Swafford wrote: >>>> >>>>>On January 16, 2006 at 16:22:10, Dann Corbit wrote: >>>>> >>>>>>On January 16, 2006 at 16:16:13, JW de Kort wrote: >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>In my engine i want to use the following line: >>>>>> >>>>>>#include <assert.h> >>>>>>... >>>>>> >>>>>> assert(kol+1 < sizeof bfZwart / sizeof bfZwart[0]); >>>>>>> !(bfZwart[kol+1]&bfBoven[rij]) >>>>> >>>>>That's probably it, but another (less likely) possibility is that >>>>>the short-circuit evaluation is not attempting fetch the value from >>>>>the bfBoven[] array unless kol+1 > 1 (making bfZwart[kol+1] true). >>>>> >>>>>In other words, is it the case that bfZwart[kol+1] always evaluates >>>>>to false? If so, I doubt the second part of the expression is even >>>>>evaluated. Like I said, not likely, but weird things happen. >>>>> >>>> >>>>By false/true I should say 'non-zero/zero', since we are dealing >>>>with a bitwise operator. >>>> >>>> >>>> >>>>>-- >>>>>James >>>>> >>>>> >>>>>>> >>>>>>>In only a few cases this lines crashes my engine. If i change the +1 to any >>>>>>>other value there is no problem! >>>>>>> >>>>>>>Does anybody know were i have to look for to solve this problem? I do not >>>>>>>understand how a comparison like the above can cause a program to crash. >>>>>>> >>>>>>>regards >>>>>>>Jan Willem
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.