659867589 >> 32 != 0 ?

[Gast]

Warum ergibt beim Vsiual c++ 2003 unsigned int test = 659867589;
cout << (test >> 32) << endl;
cout << (659867589>> 32) << endl;
Ausgabe:
659867589
0


was kann ich dagegen tun?

[Gast]

beim gcc genauso
test.cpp:7: warning: right shift count >= width of type
test.cpp:8: warning: right shift count >= width of type

ich glaub ich nehm unsigned long long und nicht unsigned int.

oder gibts noch andere möglichkeiten?

[ethrandil]

Original geschrieben von Gast ich glaub ich nehm unsigned long long und nicht unsigned int.

oder gibts noch andere möglichkeiten?
Wofür brauchst du das denn, wenn ich mal ganz doof fragen darf?
ansonsten teste doch mal:

test >> 31 >> 1

Dann ist keine zahl >= der intlänge, vorraussetzung ist natürlich, dass int 32 bit hat.

Außerdem bringt das herzlich wenig.
>>31 >> 1
macht aus jedem integer 0 !
also ginge auch test = 0
Wenn du aber 32 bit erschiebung brauchst, dann reicht dein zahlenbereich ohnehin nicht aus.

[Demirug]

Was willst du damit erreichen wenn du einen 32 Bit wert um 32 Stellen verschiebst? Da muss 0 herauskommen.

[Magnum]

Ich glaube, er will darauf hinaus, dass in der ersten Anweisung etwas ungleich 0 herauskommt und bei der zweiten etwas gleich 0.
Die große Frage ist hier also: Warum?

[Tom Servo]

Denke es liegt daran, dass im einen Fall >> von der CPU berechnet wird, und dabei das Vorzeichen (trotz des unsigned Typs) immer nachgezogen wird.

Bei den Literalen wird es vom Compiler berechnet, und dort wird es offenbar nicht gemacht.

Ist glaube ich so im Standard definiert, dass >> je nach CPU anders funktionieren kann.

Naja, möchte das aber nicht beschwören.

[Xmas]

Original geschrieben von Tom Servo
Denke es liegt daran, dass im einen Fall >> von der CPU berechnet wird, und dabei das Vorzeichen (trotz des unsigned Typs) immer nachgezogen wird.

Bei den Literalen wird es vom Compiler berechnet, und dort wird es offenbar nicht gemacht.

Ist glaube ich so im Standard definiert, dass >> je nach CPU anders funktionieren kann.

Naja, möchte das aber nicht beschwören.
Das mit dem Vorzeichen nachziehen stimmt zwar nicht, aber du hast recht dass es sich um eine CPU-Sache handelt.

Zu SHR: (http://folk.uio.no/botnen/intel/vt/reference/vc283.htm)
"The 8086 does not mask the shift count. However, all other Intel® Architecture processors (starting with the Intel® 286 processor) do mask the shift count to 5 bits, resulting in a maximum count of 31. This masking is done in all operating modes (including the virtual-8086 mode) to reduce the maximum execution time of the instructions."
Eine x86-CPU nimmt lediglich die untersten 5 Bits des Operanden, deswegen ist test >> 33 auch identisch zu test >> 1.

Zu operator>>:
"The results are undefined if the right operand of a shift expression is negative or if the right operand is greater than or equal to the number of bits in the (promoted) left operand."
Damit ist das Verhalten auch "standardkonform", denn das Ergebnis ist schlicht undefiniert.