Resultados inesperados de cambio de bits

Question

Estoy inicializando un int corto sin signo con a = 0xff (todos los bits están configurados). Luego asigno b a un & Gt; & Gt; 7 que debería rendir (0000 0001) y lo hace. Sin embargo, lo extraño es que cuando asigno c a & Lt; & Lt; 7, no es equivalente a (1000 0000). Probé esto generando 0x80 (que es 1000 0000) yc, pero no son lo mismo.

Aquí hay un código:

unsigned short int a = 0xff;
unsigned short int b = a>>7;
unsigned short int c = a<<7; // c should == 0x80

No estoy seguro de cuál es el problema. Cualquier ayuda es apreciada. Gracias.

P.S. Por & Quot; salida & Quot; Me refiero a la salida 0x80 yc en forma decimal y hexadecimal.

Answer 1

un int corto tiene 16, no solo 8 bits.

Por lo tanto, es probable que obtenga " 0111 1111 1000 0000 " como resultado de 0xff < < 7.

Answer 2

No adivine los tipos de bits, use <stdint.h>

---

Un breve int " generalmente " tiene 16 bits. En realidad, estoy bastante seguro de que siempre tiene 16, excepto para esas computadoras marcianas, pero eso no es algo que promete el estándar.

Si desea declarar tipos que tienen un número específico de bits, la técnica de conformación es:

#include <stdint.h>

  int8_t  a;
 uint8_t  b;
 int16_t  x;
uint16_t  y;

Hacer esto habría evitado su conjetura no completamente correcta en la representación de bits de short. Por alguna razón, Microsoft está muy lejos de cumplir con el estándar C99, incluso en cosas fáciles como <=>. Afortunadamente, un proyecto mantiene una versión estándar VC ++ .

Answer 3

Espero que tengas 0x7f80. Creo que lo que querías escribir es:

unsigned short int c = b<<7; // c should == 0x80

Answer 4

Desafortunadamente, VC ++ (el compilador de C) no tiene inttypes.h porque no es totalmente compatible con C99. Debe usar encabezados de terceros (por ejemplo, stdint.h de Paul Hsieh).

Answer 5

Si desea obtener ese resultado, puede cortar la porción a << 7 mayor que el octavo bit menos significativo, utilizando bitwise-y:

unsigned short int c = (a << 7) & 0xff;