Немного мудрый ‘& amp;’ с подписанным против неподписанного операнда

Первое, что нужно понять, это то, что бинарные операторы, такие как a&b для встроенных типов работают, только если обе стороны имеют одинаковый тип. (С пользовательскими типами и перегрузками все идет). Это может быть реализовано с помощью неявных преобразований.

Теперь, в вашем случае, определенно есть такое преобразование, потому что просто нет бинарного оператора & который принимает тип меньше, чем int, Обе стороны преобразуются как минимум int размер, но какие именно типы?

Как это происходит, на вашем GCC int действительно 32 бита. Это важно, потому что это означает, что все значения uint16_t может быть представлен в виде int, Там нет переполнения.

Следовательно, check & 0xFFFF это простой случай. Правая сторона уже int, левая сторона способствует intтак что результат int(0x8123), Это прекрасно.

Теперь следующая операция 0x8123 << 16, Помните, в вашей системе int составляет 32 бита, и INT_MAX является 0x7FFF'FFFF, При отсутствии переполнения, 0x8123 << 16 было бы 0x81230000, но это явно больше, чем INT_MAX так что на самом деле переполнение.

Целочисленное переполнение со знаком в C ++ 11 — неопределенное поведение. Буквально любой результат является правильным, в том числе purple или вообще не выводить. По крайней мере, вы получили числовое значение, но GCC, как известно, прямо исключает пути кода, которые неизбежно вызывают переполнение.

Давайте посмотрим на

uint64_t new_check = (check & 0xFFFF) << 16;

Вот, 0xFFFF это константа со знаком, так (check & 0xFFFF) дает нам целое число со знаком по правилам целочисленного продвижения.

В вашем случае с 32-битным int тип, MSbit для этого целого числа после сдвига влево равен 1, и поэтому расширение до 64-разрядного беззнакового будет делать расширение знака, заполняя биты слева 1. Интерпретируется как представление дополнения до двух, которое дает одинаковое отрицательное значение.

Во втором случае 0xFFFFU является беззнаковым, поэтому мы получаем целые числа без знака, и левый оператор сдвига работает как ожидалось.

Если ваш инструментарий поддерживает __PRETTY_FUNCTION__Наиболее удобная функция, вы можете быстро определить, как компилятор воспринимает типы выражений:

#include <iostream>
#include <cstdint>

template<typename T>
void typecheck(T const& t)
{
std::cout << __PRETTY_FUNCTION__ << '\n';
std::cout << t << '\n';
}
int main()
{
uint16_t check = 0x8123U;

typecheck(0xFFFF);
typecheck(check & 0xFFFF);
typecheck((check & 0xFFFF) << 16);

typecheck(0xFFFFU);
typecheck(check & 0xFFFFU);
typecheck((check & 0xFFFFU) << 16);

return 0;
}

Выход

void typecheck(const T &) [T = int]
65535
void typecheck(const T &) [T = int]
33059
void typecheck(const T &) [T = int]
-2128412672
void typecheck(const T &) [T = unsigned int]
65535
void typecheck(const T &) [T = unsigned int]
33059
void typecheck(const T &) [T = unsigned int]
2166554624

0xFFFF является подписанным Int. Так что после & операция, у нас есть 32-битное значение со знаком:

#include <stdint.h>
#include <type_traits>

uint64_t foo(uint16_t a) {
auto x = (a & 0xFFFF);
static_assert(std::is_same<int32_t, decltype(x)>::value, "not an int32_t")
static_assert(std::is_same<uint16_t, decltype(x)>::value, "not a uint16_t");
return x;
}

http://ideone.com/tEQmbP

Затем ваши исходные 16 бит смещаются влево, что приводит к 32-битному значению с установленным старшим битом (0x80000000U), поэтому оно имеет отрицательное значение. Во время 64-битного преобразования происходит расширение знака, заполняющее верхние слова 1с.

Это результат целочисленного продвижения. Перед & операция происходит, если операнды «меньше», чем int (для этой архитектуры), компилятор будет продвигать оба операнда intпотому что они оба вписываются в signed int:

Это означает, что первое выражение будет эквивалентно (в 32-битной архитектуре):

// check is uint16_t, but it fits into int32_t.
// the constant is signed, so it's sign-extended into an int
((int32_t)check & (int32_t)0xFFFFFFFF)

в то время как у второго будет второй операнд:

// check is uint16_t, but it fits into int32_t.
// the constant is unsigned, so the upper 16 bits are zero
((int32_t)check & (int32_t)0x0000FFFFU)

Если вы явно бросили check для unsigned int, тогда результат будет одинаковым в обоих случаях (unsigned * signed приведет к unsigned):

((uint32_t)check & 0xFFFF) << 16

будет равен:

((uint32_t)check & 0xFFFFU) << 16

Ваша платформа имеет 32-разрядную версию int,

Ваш код в точности соответствует

#include <iostream>
#include <cstdint>

int main()
{
uint16_t check = 0x8123U;
auto a1 = (check & 0xFFFF) << 16
uint64_t new_check = a1;
std::cout << std::hex << new_check << std::endl;

auto a2 = (check & 0xFFFFU) << 16;
new_check = a2;
std::cout << std::hex << new_check << std::endl;
return 0;
}

Какой тип a1 а также a2?

• За a2, результат повышен до unsigned int,
• Более интересно, для a1 результат повышен до int, а затем он становится расширенным как uint64_t,

Вот более короткая демонстрация в десятичной форме, так что разница между типами со знаком и без знака очевидна:

#include <iostream>
#include <cstdint>

int main()
{
uint16_t check = 0;
std::cout << check
<< "  " << (int)(check + 0x80000000)
<< "  " << (uint64_t)(int)(check + 0x80000000) << std::endl;
return 0;
}

На моей системе (также 32-битной int), Я получил

0  -2147483648  18446744071562067968

показывая, где происходит продвижение и подписка-расширение.

& Операция имеет два операнда. Первый — это неподписанный шорт, который будет проходить обычные акции, чтобы стать int. Второй является константой, в одном случае типа int, в другом случае типа unsigned int. Результат & следовательно, int в одном случае, unsigned int в другом случае. Это значение сдвигается влево, что приводит либо к int с установленным битом знака, либо к unsigned int. Приведение отрицательного значения int к uint64_t даст большое отрицательное целое число.

Конечно, вы всегда должны следовать правилу: если вы что-то делаете и не понимаете результата, не делайте этого!