I was on the C language standards committee (X3J11) ... in fact, I was the first person in the world to vote in favor of adoption of the standard (alphabetic privilege) ... and I can tell you authoritatively that this is wrong. Yes, the standard says that a char cannot be bigger than an int, and does not specify how many bits are in a char--nevertheless, sizeof(char) == 1 and cannot be otherwise (the standard does not state this explicitly, although I think it may have made it into a footnote, but it can be logically derived). You could, for instance, have 32-bit chars and 32-bit ints, in which case sizeof(char) == sizeof(int) == 1. I don't know why you think otherwise.

"In mainstream compilers you get a negative number, since the number space wraps around. But the C standard says the result is undefined."

I hadn't realized that there's anyone alive who wasn't aware of this.

"So some compilers will leave a at the maximum value, MAX_INT."

This isn't a function of the compiler, but of the host hardware. (But it's pretty weird hardware that clamps at the max integer value.) In fact this is *why* the C standard leaves such things undefined--so that compilers don't have to generate extra code to force the computer to produce results that are "unnatural" for the machine's architecture. (Java takes a different approach, where all results are strictly defined, so such extra code does need to be generated for unusual hardware. And Java requires that bytes are 8 bits and cannot be made to work on hardware with a different byte size).

"And don't even think about bit-shifting a negative number: "

Right ... which is why one should use the / operator, and then examine the generated code to see if the compiler is smart enough to optimize division by powers of 2.

Another problem is shifting by >= the number of bits in the operand ... e.g., i >> 32 is undefined if i is a 32-bit int. This is to accommodate the Intel architecture, which stores the shift amount in 5 bits of the instruction, so a shift by 32 is actually a noop because (32 & 0x1f) == 0. I've seen more than one instance of this bug in widely distributed code.

Your tips here are rather basic. For something a bit meatier, see graphics.stanford.edu/~seander/bithacks.html

In loops, else flattening can even omit else:

for() {

    if(A) {

        ...

        continue;

    }

    if(B) {

        ...

        continue;

    }

    if(C) {

        ...

        continue;

    }

}

If you are a C expert, please try this challenge:

http //www.linkedin.com/groups?gid=4264441

This is wrong. On all compilers sizeof(char) is 1. The C standard defines sizeof in terms of numbers of chars, since a char is one byte. If sizeof(char) is not 1, you're not using a conforming C compiler.

branch prediction: but the lookup table is then mispredicted all the time, whereas the nested ifs are correctly branch predicted ~always and therefore free.

this blog is awesome :) all mediocre programmers should advertise themsleves widely so they, and their followers can be screened.

rather serious not nice Danger: your flags carry into the next flag if it is set twice. |= would probably be better, (or perhaps a language that doesn't use smileys <= ?:) (or perhaps less than a million settings ;)

settingsSoFar+=1<<(5-1)

No, sorry, that is wrong. sizeof(char) is always 1, and the sizeof all other types is measured in chars. Even if a character is stored as 2 or 4 bytes on some platform, sizeof(char) will equal 1. And don't forget that a "byte" is not 8 bits on every architecture.

On the ternary conditional operator ?: : yes it saves on typing but it's dog-slow compared to a switch statement. Save it for when a switch statement won't work (for instance, when an expression must be reevaluated if it doesn't match). The example you gave is the perfect time to use a switch statement, although your default case should be "str = rand() == 42?"four":"unknown number";break; to make the nested ?: code.

On DeMorgan's: This is CompSci 101, or 201 at the latest. They teach you precisely this in school.

On rounding: this code is not portable to platforms where a sizeof(char) is not 8. For chars the code should be unsigned char bitmap [NUMBER_OF_BITS + sizeof(char)-1/sizeof(char)]; You should be able to figure out how to do that with ints as well.

On real rounding: The best one of the list.

On bit-shifting: if they don't teach you this in school, you're at the wrong school. Same if they don't tell you that if you want multiplication, unless you have hardware reasons to bit-shift (side-effects in a MIPS processor, for instance), you should simply multiply. Let the complier sort it out. The compiler knows better than you, for instance, that multiplication always works, but weird things can happen on certain models of 64-bit processors running in 32-bit mode if you shift left by 32.

Else flattening: seriously dude, what crappy school did you go to that they didn't tell you about this?

On non-mainstream compilers: indeed, so apply that to your own examples! And bit-shifting a negative number works exactly as well as bit shifting a positive number, which is to say, again, if you want multiplication (or division), JUST DO IT!

// Set the xth bit (to 1).

flags |= 1 << x;

// Clear the xth bit (set it to 0).

flags &= ~(1 << x);

// Flip the xth bit (if it's set, clear it; if it's clear, set it).

flags ^= 1 << x;

// Extract the xth bit as an integer and store it in test.

test = flags >> x & 1;

#define elif else if

Assuming you are in an environment where saving memory is more precious than saving time, you can do so by "packing" information into casual numbers.

E.g. you've got 32 boolean flags determining settings of your program. Then you can save 1 to 5-th flag by doing:

settingsSoFar+=1<<(5-1)

Extracting is analogous.

Modus ponendo tollens.