Есть ли смысл выполнять двоичные И с числом, где все биты установлены в 1 - PullRequest
1 голос
/ 27 марта 2010

Приветствую всех. Я видел примеры таких операций столько раз, что начинаю думать, что что-то не так с двоичной арифметикой. Есть ли смысл выполнять следующее:

byte value = someAnotherByteValue & 0xFF;

Я действительно не понимаю этого, потому что это все равно ничего не меняет. Спасибо за помощь.

P.S. Я пытался искать информацию как в других местах, так и здесь, но безуспешно.

EDIT: Ну, конечно, я предполагаю, что someAnotherByteValue имеет длину 8 бит, проблема в том, что я не понимаю, почему так много людей (я имею в виду профессионалов) используют такие вещи в своем коде. Например, в SharpZlib есть:

     buffer_ |= (uint)((window_[windowStart_++] & 0xff |
     (window_[windowStart_++] & 0xff) << 8) << bitsInBuffer_);

где window_ - это байтовый буфер.

Ответы [ 7 ]

3 голосов
/ 27 марта 2010

Наиболее вероятная причина - сделать код более самодокументированным. В вашем конкретном примере важен не размер someAnotherByteValue, а тот факт, что value является байтом. Это делает & избыточным на всех языках, которые я знаю. Но, чтобы привести пример, где это было бы необходимо, если бы это была Java, а someAnotherByteValue было byte, то строка int value = someAnotherByteValue; могла бы дать совершенно другой результат, чем int value = someAnotherByteValue & 0xff. Это связано с тем, что типы Java long, int, short и byte подписаны, а правила преобразования и расширения знака должны быть учтены.

Если вы всегда используете идиому value = someAnotherByteValue & 0xFF, то, независимо от типа переменной, вы знаете, что значение получает младшие 8 битов someAnotherByteValue.

3 голосов
/ 27 марта 2010
uint s1 = (uint)(initial & 0xffff);

В этом есть смысл, потому что uint - это 32 бита, а 0xffff - 16 бит. В строке выбираются 16 младших значащих битов из initial.

2 голосов
/ 27 марта 2010

Нет .. В этом нет смысла. Если вы используете значение, значение которого превышает 8 бит, то приведенное выше утверждение имеет некоторый смысл. В противном случае он совпадает с вводом.

1 голос
/ 27 марта 2010

Если sizeof(someAnotherByteValue) больше 8 бит, и вы хотите извлечь 8 битов младших разрядов из someAnotherByteValue, то это имеет смысл. В противном случае, нет смысла.

0 голосов
/ 27 марта 2010

Чтобы быть разборчивым, нет никаких гарантий относительно размера байта машины. В чрезвычайно переносимой программе нет оснований предполагать, что ширина архитектурного байта составляет 8 бит. Насколько я помню, в соответствии со стандартом C (например), char - это один байт, short - шире или такой же, как char, int - шире или такой же, как short, long шире или такой же, как int и скоро. Следовательно, теоретически может существовать компилятор, в котором long на самом деле имеет ширину в один байт, а этот байт будет, скажем, шириной 10 бит. Теперь, чтобы ваша программа работала одинаково на этом компьютере, вам нужно использовать этот (на первый взгляд избыточный) стиль кодирования.

"Байт" @ Википедия приводит примеры таких своеобразных архитектур.

0 голосов
/ 27 марта 2010

РЕДАКТИРОВАТЬ: Ну, конечно, я предполагаю, что someAnotherByteValue имеет длину 8 битов, проблема в том, что я не понимаю, почему так много людей (я имею в виду профессионалов) используйте такие вещи в своем коде. За пример в MiscUtil Джона Скита есть это:

uint s1 = (uint) (начальный & 0xffff);

где начальное значение int.

В этом конкретном случае автор может пытаться преобразовать int в uint. Символ & with 0xffff гарантирует, что он все равно преобразует 2 младших байта, даже если система не имеет 2-байтового типа int.

0 голосов
/ 27 марта 2010

Нет, бессмысленно, пока вы имеете дело с байтом. Если бы value было длинным, то младшие 8 битов были бы младшими 8 битами someAnotherByteValue, а остальные были бы равны нулю.

На таком языке, как C ++, где операторы могут быть перегружены, возможно , но вряд ли оператор & был перегружен. Это было бы довольно необычно и плохой практикой.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...