I got a interview question previous like this:
find what might be wrong
if (mask & ASYNC_BIT == 0x0100) {....
No values were defined for both "mask" and ASYNC_BIT in the question, just wonder in what condition the result of "AND" operation could not compare with hex value.
Syntactically: == comes first, & comes second.
The order of precedence between those operations are "bad": you first do the ==, then do the and for some reason. You need parenthesis to make it right, e.g.
Without parenthesis, it becomes:Code:if ((mask & ASYNC_BIT) == 0x0100)
which turns into an and with either 1 or 0.Code:if (mask & (ASYNC_BIT == 0x0100))
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Oh that's really basic thing and I understand why i made a mistake then.
thx
I wouldn't have known that without looking at a precedence table. I'd tell the interviewers I can answer the question if they either show me a precedence chart or put some parentheses in.
Aside from cpjust's answer, I have made the mistake of writing code like that so many times that I'm now ACTIVELY thinking about it when I'm writing bit-checking/bit-twiddling code - a bit like someone who's flooded the bathroom 6 times will double and tripple-checkl that they haven't left the taps on.Originally Posted by pinklax
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
