I musn't be thinking about something right (or maybe left)! If I have the number '1', which in binary is this...

1000 0000

...and I do a right shift on it to get this...

0100 0000

then that should give me '2', not??? Then why doesn't this work...

``````#include <stdio.h>

int main(void)
{
char x=1;

x=x>>1;
printf("x=%d\n",x);
getchar();

return 0;
}

//x=0``````

Doesn't x=x>>1 mean 'Shift 1 to the right 1 bit? Isn't that 2? Here is my program to shift 1 across all 8 bits. Notice I'm using left shift - not right shift. That doesn't make sense to me. The output you see below the program is what I want (what I'm wanting to create is an and mask), but I'm having to use the bit shift operator backwards from what I'm thinking it should be. Can someone please set my head right (or left) on this??????!!!!!!

``````#include <stdio.h>

int main(void)
{
unsigned char x=1;

printf("i\t1<<i\n");
printf("==============\n");
for(unsigned i=0; i<8; i++)
{
x=1<<i;
printf("%u\t%d\n",i,x);
}
getchar();

return 0;
}

/*
i       1<<i
==============
0       1
1       2
2       4
3       8
4       16
5       32
6       64
7       128
*/``````

What you are experiencing is the result of "endianess" which is a system-specific behavior. However, most modern systems have a "little-endian" configuration.

In a little-endian configuration, the right-most bit of a word represents the smallest value (i.e. 1). Thus, if you have a 32-bit int whose value is one (1) it's actually:

``0000 0000 0000 0000 0000 0000 0000 0001``

Which is why the left shift works the way you think the right shift should.

EDIT:
Oops, just a touch slow...

Actually, endianness is irrelevant here. The logical behavior of shifting is the same regardless of how the underlying values are actually stored.

commented: good to know. :) +5

Really...?

So perhaps a better way to say it is that C++ abstracts that away and always uses or assumes "little-endian" logic?

That's good to know...

Geez, I know darned well disagreeing with you on any C++ matter is a losing proposition Narue, but FBody's idea is the only thing that works in my mind. I mean, this '>>' is right shift right? And right shifting 1000 0000 by 1 bit should give 0100 0000, right? But it doesn't. One must do a left shift on 1000 0000 to get a 2, and a left shift on 1000 0000 should give zero as the left most bit is shifted into nothingness?

Unless I've got the operator - operand thing mixed up.

You seem to have the bit-shifting concept correct.
If (in binary) x=(1000 0000) and you perform the operation x >>= 1 (shift right one bit), you will get x==(0100 0000).

The issue is that you have the values of the bit positions themselves backward.

The decimal-equivalent value of binary (1000 0000) is not one (1), it's 128. Thus, the result of x >>= 1 is 64.

But the results speak for themselves. You can't argue away what the output is. As crazy as it seems, MY THINKING IS BACKWARD.

Ahhh! I got it now! Somehow I switched that around in my mind!!! I really don't do these things all that much, and just got it backward. Thanks FBody and Narue! Really had me mystified!

Fred

>>But the results speak for themselves.
Yes, they do.

The Integer value 1 is not represented as 1000 0000 0000 0000 0000 0000 0000 0000
as you assume.

It is represented as 0000 0000 0000 0000 0000 0000 0000 0001

EDIT:
Oops, overlap...

Glad the light came on. :)