Ответьте на вопрос об интервью практики
Я просто прохожу набор вопросов об интервью C++ только, чтобы удостовериться, что нет ничего очевидного, что я не знаю. До сих пор я не нашел ничего, что я уже не знал, кроме этого:
long value;
//some stuff
value &= 0xFFFF;
Вопрос "что случилось с этим кодом?" И подсказки, что это - что-то, чтобы сделать с целевыми архитектурами.
Если ответ не является просто "значением, не инициализируется", я не вижу проблемы. Насколько я могу сказать, это просто маскирует 2 младших значащих байта значения, и long как гарантируют, будет по крайней мере 2 байта, таким образом, нет никакой проблемы там.
Это могло возможно быть это long могли бы только быть 2 байта на целевой архитектуре, и Вы могли бы терять знаковый бит? Или возможно что 0xFFFF int и int только 2 байта?
Заранее спасибо.
6 ответов
Проблема с этим кодом заключается в том, что он выполняет побитовую операцию со значением со знаком. Результаты таких операций с отрицательными значениями сильно различаются для разных целочисленных представлений.
Например, рассмотрим следующую программу:
#include <iostream>
int main(void)
{
long value;
value = -1; // Some stuff
value &= 0xffff;
std::cout << "Value = " << value << std::endl;
}
В архитектуре с дополнением до двух результат будет следующим:
Value = 65535
В архитектуре с дополнением до единицы результат будет следующим:
Value = 65534
В архитектуре знака и величины результат будет следующим: :
Value = 1
Могу я сказать, что в этом коде нет ничего плохого, если не известен контекст или намерение окружающего кода!
Это может быть выстрел в темноте, но если предположить, что long vs int не является проблемой (другие публиковали ответы, отвечающие именно на это) и что 0xFFFF охватывает всю сумму, требуемую типом Разве это не приведет к тому, что value = 0xFFFF , и нет необходимости в манипуляции с битами? Разве манипуляции с битами не являются избыточными?
Единственное, что я могу видеть, это то, что человек, задающий вопрос, хочет, чтобы вы поняли, что на недостающие данные, содержащиеся в long, не повлияет простое использование 0xFFFF.
Мне кажется немного странным вопрос, который нужно задавать, исходя из того, как этот вопрос здесь представлен, или, может быть, он настолько очевиден, что мы все время думаем об этом :)
Трудно понять, что интервьюер ожидал от вас. Мы вроде как должны догадываться.
Я предполагаю, что на некоторых архитектурах 0xFFFF будет 16-битным значением со знаком, а long - 32-битным значением со знаком. Когда вы расширяете константу так, чтобы ее можно было использовать для маскировки длинного значения, знак будет расширен и станет 0xFFFFFFFFl, что совсем не то, что вы планировали.
Приложение: Написанный код корректно работает на всех трех компиляторах, которые я использую в настоящее время, так что это действительно игра в угадывание, пытаясь выяснить, что имел в виду интервьюер. Правильно соответствующий стандартам 16-битный компилятор также сгенерирует правильный код, поэтому нам остается гадать, что-то мы пропустили, действительно ли пример не сломан, или интервьюер когда-то использовал 16-битный компилятор, который будет рассматривать 0xFFFF как подписанное количество, когда его заставляют продлить до длинного. Было бы интересно его спросить.
Я подозреваю, что мы все слишком много думаем.
Что не так в этом коде, так это то, что значение не инициализировано. Вопрос в том, понимаете ли вы, что & = (или + =, - = / = и т. Д.) Бессмысленно при использовании с унифицированным значением?
Если значение инициализировано, то поведение хорошо определено. Младшие 16 битов сохраняются, остальные обнуляются
для меня звучит как Big-Endian vs. Little-Endian. http://en.wikipedia.org/wiki/Endianness