Public Group

why!? why!? WHY!?!? bitwise hell

This topic is 4264 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

int _tmain(int argc, _TCHAR* argv[])
{
int index = 85, up = -16, yay = 2;
int temp = index + up * yay;
int temp2 = temp & 0x88;
if((index + up * yay) & 0x88 != 0)
{
bool ok = false;
}
return 0;
}


This is based on a problem I am having with my program. Go through it in the debug. temp = 53. ok temp2 = 0. ok but the if statement carrys through WHY WHY WHY WHY AHGHRHGHA AHGAGHA RARHGHGHGHGHA ARGHGHGHGHGH

Share on other sites
53 & 0x88 is best done after we convert to binary, correct? So lets do that first. 53 in binary is 00110101, 0x88 in binary is 10001000 (if memory serves...been a while since I've done hex to binary conversions). Performing an & operation on these two numbers results in

00110101
& 10001000
----------
00000000

Are you saying this if check is returning true (therefore entering the following body)? If that's the case you have me stumped. When you say the if statement carries through, do you mean to say it is being evaluated to true?

EDIT: for some reason I can't get my binary numbers to line up in the operation above, sorry for any confusion. The leading values should line up with one another.

Share on other sites
Ahh, now that makes sense. because the != has higher precedence, the 0x88 != 0 is evaluated first. This will return to us true or 1. if we do the & operation on 53 and 1 we get

00110101
& 00000001
----------
00000001

which is non-zero, therefore true.

Share on other sites
EDIT: Oops! I should refresh the page before answering... I thought that I had the first reply :D

This should do the trick:

if(((index + up * yay) & 0x88) != 0)

Actually, I agree with you, IIRC the bitwise and should be done before the inequallity operator...

I'll go back to study C++ again...

Share on other sites
OK it works now thanks, but I have to say whoever designed the precedence is stupid.

Share on other sites
Why? At some point a choice must be made; just because you don't like it because it caused you a problem doesn't make it stupid. You could make valid cases for either option. Just deal with it.

Share on other sites
Sorry, you just have NO idea how long I spent trying to figure this out ;P It just seems a bit counter-intuitive to me.

Share on other sites
operator precedence doesn't really have to do with intuition. The order could just as easily be the other way around. It is arbitrary (as far as I know) and only exists because it has to. The language requires standards such as this, otherwise it wouldn't work.

I doubt you really spent that long on this problem relative to some of the other more complex issues you'll run into in game development or programming in general. When you've spent 4 days debugging your octree implementation, then we'll talk :)

Just be aware of the language intricacies. They don't always make sense immediately but they exist for a reason, without these rules, the language itself would fall apart.

Share on other sites
Quote:
 Original post by Morpheus011It is arbitrary (as far as I know) and only exists because it has to.

Actually it isnt. Its based on math.

You probrably already know this from grade 10 math, but lets look at some simple math equations.

1 x 3 + 5 = 8
Resolves to
(1 x 3) + 5 = 8
..to...
(3) + 5 = 8

So, in math, multiplication has a higher precedence then addition.

Or

1 x 2 + 6 / 3 = 4
==
(1x2) + (6/3) = 4
==
(2) + (2) = 4

Notice how in both equations I used () to denote things that come first. Thats because, like in math, () give you the option of raising operator precedence.

So, for example:
(3+6) X 2 = 18
--
(9) X 2 = 18

Then, you can nest paranthesis, such as
(3 x ( 3+2))/2 = 7.5
==
(3 x (5))/2 = 7.5
==
(15)/2 = 7.5
==
15/2 = 7.5

It just so happens that since bitwise math is as "basic" math as computers get, they have the highest precedence ( are evaluated first ), unless over ridden by ( ) markers.

There is actual logic behind how languages implement operator precedence.

• 9
• 16
• 9
• 13
• 41