Respuesta a una pregunta de la entrevista de práctica

Question

Estoy pasando por un montón de preguntas de la entrevista de C++ solo para asegurarme de que no haya nada obvio que yo no sé. Hasta el momento no he encontrado nada que no sabía ya, salvo esto:

long value; 
//some stuff 
value &= 0xFFFF; 

La pregunta es "¿qué hay de malo con este código" Y sugiere que se trata de algo relacionado con las arquitecturas de destino.

A menos que la respuesta sea solo "el valor no se ha inicializado", no puedo ver ningún problema. Por lo que puedo decir, solo está enmascarando los 2 bytes menos significativos del valor, y se garantiza que long tendrá al menos 2 bytes, por lo que no hay ningún problema.

¿Es posible que long solo tenga 2 bytes en la arquitectura de destino y es posible que pierda el bit de signo? O tal vez que el 0xFFFF es un int y int tiene solo 2 bytes?

Gracias de antemano.

Answer 1

Este problema con este código es que hace una operación poco sabia en un valor firmado. Los resultados de tales operaciones en valores negativos varían mucho para diferentes representaciones enteras.

Por ejemplo, consideremos el siguiente programa:

#include <iostream> 

int main(void) 
{ 
    long value; 
    value = -1; // Some stuff 
    value &= 0xffff; 
    std::cout << "Value = " << value << std::endl; 
} 

en una arquitectura de complemento a dos el resultado es:

Value = 65535 

en una arquitectura one's-complemento, el resultado es:

Value = 65534 

En una arquitectura de signo y magnitud el resultado es:

Value = 1 

Answer 2

suena como Big-Endian vs. Little-Endian para mí. http://en.wikipedia.org/wiki/Endianness

Answer 3

Es difícil saber lo que el entrevistador esperaba que dijera. Tenemos que adivinar.

Supongo que en algunas arquitecturas, 0xFFFF será un valor firmado de 16 bits, mientras que long es un valor firmado de 32 bits. Cuando extiendes la constante para que se pueda usar para enmascarar el valor largo, el signo se extenderá y se convertirá en 0xFFFFFFFFl, que no es lo que pretendías en absoluto.

Adición: El código como obras escritas correctamente en los tres de los compiladores que uso actualmente, así que esto es de hecho un juego de adivinanzas de tratar de averiguar lo que el entrevistador pretende. Un compilador de 16 bits que cumpla con los estándares también generaría el código correcto, por lo que nos quedamos adivinando si hay algo que fallamos, si el ejemplo no está roto o si el entrevistador alguna vez usó un compilador de 16 bits que trataría 0xFFFF como una cantidad firmada cuando se lo fuerza a extenderlo a un largo. Sería interesante preguntarle.

Answer 4

¡Puedo decir, no hay nada de malo en este código a menos que se conozca el contexto o la intención del código que lo rodea!

Answer 5

Esto podría ser un tiro en la oscuridad, pero suponiendo que el largo vs int no es el problema (otros han publicado respuestas que respondan precisamente eso) y que el 0xFFFF abarca la cantidad total requerida por el tipo, ¿no sería esto? solo está haciendo value = 0xFFFF y no hay necesidad de manipular el bit? ¿No es redundante la manipulación de bits?

La única otra cosa que puedo ver es si la persona que hizo la pregunta quería que se diese cuenta de que los datos faltantes contenidos en el tiempo no se verían afectados por el uso de 0xFFFF.

Para mí viene a ser un poco loco de una pregunta que hacer sobre la base de cómo se presenta aquí la pregunta o tal vez es sólo tan obvio que estamos sobre el pensamiento todo lo que :)

Answer 6

Sospecho que todos estamos pensando demasiado.

Lo que está mal con este código es que el valor no se inicializa. La pregunta es: ¿se da cuenta de que el & = (o + =, - =/= etc.) no tiene sentido cuando se usa en un valor unificado?

Si el valor se inicializa, entonces el comportamiento está bien definido. Los 16 bits menos significativos se conservan, el resto se ponen a cero