Что происходит с побитовыми операторами и целым продвижением? - программирование

Что происходит с побитовыми операторами и целым продвижением?

У меня простая программа. Обратите внимание, что я использую целое число без знака с фиксированной шириной 1 байт.

#include <cstdint>
#include <iostream>
#include <limits>

int main()
{
    uint8_t x = 12;
    std::cout << (x << 1) << '\n';
    std::cout << ~x;

    std::cin.clear();
    std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
    std::cin.get();

    return 0;
}

Мой вывод следующий.

24
-13

Я тестировал большие числа, а оператор << всегда дает мне положительные числа, а оператор ~ всегда дает отрицательные числа. Затем я использовал sizeof() и нашел...

Когда я использую побитовый оператор с левым сдвигом (<<), я получаю четырехзначное целое число без знака.

Когда я использую побитовый оператор (~), я получаю подписанное 4-байтовое целое.

Кажется, что побитовое не оператор (~) выполняет подписанную интегральную продвижение, как это делают арифметические операторы. Однако левый оператор сдвига (<<), по-видимому, способствует беззнаковому интегралу.

Я чувствую себя обязанным знать, когда компилятор что-то меняет за моей спиной. Если я правильно в своем анализе, все битовые операторы продвигают до 4 байтовых целых чисел? И почему некоторые подписываются и некоторые без знака? Я так смущен!

Изменить: Мое предположение о том, чтобы всегда получать положительные или всегда получать отрицательные значения, было неправильным. Но из-за того, что я ошибаюсь, я понимаю, что на самом деле происходит благодаря большим ответам ниже.

4b9b3361

ОТВЕТЫ

Ответ 1

[expr.unary.op]

Операнд ~ должен иметь целочисленный или неперечисленный тип перечисления; результат является дополнением к его операнду. Интегральные рекламные акции выполняется.

[expr.shift]

Операторы сдвига << и >> группируются слева направо. [...] Операнды должны быть целочисленного или не подлежащего регистрации типа перечисления и интегральных рекламных акций выполняются.

Какова интегральная поддержка uint8_t (которая обычно будет unsigned_char за кулисами)?

[conv.prom]

Значение целочисленного типа, отличного от bool, char16_t, char32_t или wchar_t, чей целочисленный ранг преобразования (4.13) меньше ранга int может быть преобразован в prvalue типа int, если int может представлять все значения типа источника; в противном случае исходное значение может быть преобразуется в prvalue типа unsigned int.

So int, потому что все значения a uint8_t могут быть представлены int.

Что такое int(12) << 1? int(24).

Что такое ~int(12)? int(-13).

Ответ 2

По соображениям производительности язык C и С++ рассматривает int как "самый естественный" целочисленный тип, а типы "меньше", чем int, относятся к типу типа "хранения".

Когда вы используете тип хранилища в выражении, он автоматически преобразуется в int или в unsigned int неявно. Например:

// Assume a char is 8 bit
unsigned char x = 255;
unsigned char one = 1;

int y = x + one; // result will be 256 (too large for a byte!)
++x;             // x is now 0

произошло то, что x и one в первом выражении были неявно преобразованы в целые числа, добавление было вычислено и результат был сохранен обратно в целое число. Другими словами, вычисление НЕ выполнялось с использованием двух символов без знака.

Аналогично, если в выражении есть значение float, первое, что сделает компилятор, это продвигать его на double (другими словами float - это тип хранилища, а double - это естественный размер для чисел с плавающей запятой). Именно по этой причине, если вы используете printf для печати поплавков, вам не нужно указывать %lf int строки формата и %f достаточно (%lf требуется для scanf, однако, поскольку эта функция сохраняет результат, а float может быть меньше double).

С++ затруднил проблему совсем немного, потому что при передаче параметров в функции вы можете различать int и более мелкие типы. Таким образом, не ВСЕГДА верно, что преобразование выполняется в каждом выражении... например, вы можете иметь:

void foo(unsigned char x);
void foo(int x);

где

unsigned char x = 255, one = 1;
foo(x);       // Calls foo(unsigned char), no promotion
foo(x + one); // Calls foo(int), promotion of both x and one to int

Ответ 3

Я тестировал большие числа и оператор < всегда дает мне положительный числа, а оператор ~ всегда дает отрицательные числа. Затем я использовал sizeof() и нашел...

Неправильно, протестируйте его:

uint8_t v = 1;
for (int i=0; i<32; i++) cout << (v<<i) << endl;

дает:

1
2
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
524288
1048576
2097152
4194304
8388608
16777216
33554432
67108864
134217728
268435456
536870912
1073741824
-2147483648

uint8_t - это 8-разрядный длинный беззнаковый целочисленный тип, который может представлять значения в диапазоне [0,255], так как этот диапазон включен в диапазон int, он продвигается до int (не ). Продвижение int имеет приоритет над продвижением до unsigned.

Ответ 4

Посмотрите два дополнения и то, как компьютер хранит отрицательные целые числа.
Попробуйте это

#include <cstdint>
#include <iostream>
#include <limits>
int main()
{
uint8_t x = 1;
int shiftby=0;
shiftby=8*sizeof(int)-1;
std::cout << (x << shiftby) << '\n'; // or std::cout << (x << 31) << '\n';

std::cout << ~x;

std::cin.clear();
std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
std::cin.get();
return 0;
}

Выходной сигнал -2147483648

В общем случае, если первый бит подписанного числа равен 1, он считается отрицательным. когда вы берете большое количество и меняете его. Если вы сдвинете его так, чтобы первый бит был равен 1, он будет отрицательным.

** ИЗМЕНИТЬ **
Хорошо, я могу думать о причине, по которой операторы сдвига будут использовать unsigned int. Рассмотрим операцию правого сдвига >>, если вы сдвигаете вправо -12, вы получите 122 вместо -6. Это связано с тем, что он добавляет нуль в начале без учета знака