Integer evenness testing (% 2 vs & 1)

Do these two statements compile equivalently: n % 2 == 0 and n & 1 == 0 ?

开发者_开发知识库if not, is one more efficient?

No, they do not always give the same result. The C standard allows for ones' complement implementations, in which case they will give a different result for negative n.

A similar question was asked yesterday.

i % 2 and i & 1 are not the same:

• If your integer is not unsigned, depending on its representation, n & 1 does not necessarily indicate whether your integer is even or odd.
• i % 2 can be negative.

For unsigned integers, a good compiler should reasonably produce equally efficient code.

That depends on your compiler.

An optimizing compiler on an x86 architecture might translate n % 2 into n & 1, since they're equivalient for 2s complement integers. A different compiler on the same platform, or the same compiler on a different platform, might give you other results.

My suggestion is to use n % 2, since that's what you're trying to accomplish in mathematical terms, and profile your application before you start micro-optimizing.

Irrespective of which one is faster, and it's unlikely that it would ever matter, n % 2 == 0 is to be preferred because it makes your intent clear. Prefer it for the same reason that you prefer writing *2 to bit shifts.

They won't compile equivalently. (Actually I should say depends on compiler. But safer to assume that compilation will be different).
(n & 1) is efficient. (Again. not sure about endian stuff, will check and let you know.)
Ok- Checked on endian stuff. It matters with the order of bytes and not the order of bits. So (n & 1) must be platform independent.

I wrote an arbitrary precision integer library in C++ once. both % and & were overloaded such that they did what you'd expect just on really big ints. Arbitrary precision modulo is very complex whereas arbitrary precision bit tests are not. Because of this insight I always prefer ( n & 1 ) since I know what is going on behind the scenes. Sure, you can say that a smart compiler might optimize ( n % 2 ) to the same instruction set as ( n & 1 ) but what you really mean is "I'm doing it wrong by using % and hoping my compiler is smarter than I am." Disregard the comments that ( n % 2 ) is easier to understand. Turns out ( n & 1 ) is pretty easy to understand too (well, maybe not for my grandmother). Use &, it's the right way.