What exactly are the effects of these operators, and how do you use them? I know that they shift bits, but in what way? I can't seem to find any documentation on this.
hex bin
0xF0 %11110000 <-- original
0x78 %01111000 <-- right shift 1
0x3C %00111100 <-- right shift 2
0x1E %00011110 <-- right shift 3
0x3C %00001111 <-- right shift 4
Right shifting by X is similar (but not exactly the same as) dividing by 2X, and left shifting by X is similar (but not exactly the same as multiply by 2X
Hmm, it seems I spoke too soon. Apparently right-shifting signed values need not use an arithmetic shift. See ISO/IEC 9899:1999 Section 6.5.7. I suppose this is due to hardware implementations of shifting operators... but personally I would think that is something simple enough for the compiler to compensate...
In any case, if you want to be sure to do an arithmetic shift in C and C++, you have to copy the sign bit yourself...
Visual C++ 2008. And I'm not sure what you mean by CPU. The manufacturer, the model, or both?
You know what, I'm just going to ask about where I'm seeing this implemented. I still can't figure out how this works.
There's an OpenGL tutorial I'm doing on loading textures, and this guy made an algorithm for loading BMP files. In it, there are a few functions for converting char arrays into shorts and ints using little-endian form, and he uses bit-shifting to accomplish it. Here's what he has:
A signed number's msb is either 0 or 1, and bit shifting should preserve that value.
An unsigned number's msb should always become zero when shifted.
For values where the msb is zero to begin with, it doesn't matter what version of shift you use (logical or arithmetic).
But if the msb is one, then it makes a difference if you are dealing with negative numbers (you want the number to remain negative after the shift).
NGen
That shifting stuff is correct and the signedness of the bytes[] array's elements is not important. Where it could be important it is fixed: 1 each element is converted to an eight-bit, unsigned quantity before shifting 2 the elements are composed using logical OR 3 the final result is converted to a signed value
However, the code does presume that an int is four bytes wide...
But wouldn't that keep the number of bits the same? From my understanding, something like "01010101 | 10101010" should return a single byte value of "11111111", not combine the 2. Or does the shifting make room for the new values when casted?
The way I see it, the guy is shifting the bits of each char so that they can be ORed into a new 4-byte value. That's the only way this would make any sense. Otherwise, he would just be shifting chars into chars, and would probably end up with either all true bits, or 1 or 2 false bits (although, most would probably be moved out of range and the whole byte would probably be '00000000'). Here's what I'm talking about:
That's what I think he's doing, since it makes the most sense. I think the casting treats the chars as ints (he casts them as an int at the beginning of the function), and basically just fills in 24 bits after the char byte, as I showed earlier.