Эквивалентно ли арифметическое переполнение операции по модулю?

unsigned char c = UCHAR_MAX;
c++;

В основном да, переполнения нет, но не потому, что c имеет беззнаковый тип. Здесь есть скрытое преобразование c в int и целочисленное преобразование из int в unsigned char, и это прекрасно определено.

Например,

 signed char c = SCHAR_MAX;
 c++;

также не является неопределенным поведением, поскольку фактически эквивалентно:

c = (int) c + 1;

и преобразование из int в signed char определяется здесь реализацией (см. c99, 6.3.1.3p3 о преобразованиях целых чисел). Для упрощения предполагается CHAR_BIT == 8.

Для получения дополнительной информации о приведенном выше примере я предлагаю прочитать этот пост:

"Маленькая функция C из ада"

http://blog.regehr.org/archives/482

Очень вероятно, что да, но причины этого в данном случае на самом деле довольно сложные.

unsigned char i = 255;
i++;

i++ эквивалентно i = i + 1.

(Ну, почти. i++ дает значение i до, которое было увеличено, так что оно действительно эквивалентно (tmp=i; i = i + 1; tmp). Но поскольку в этом случае результат отбрасывается, это не вызывает никаких дополнительных проблем.)

Поскольку unsigned char является узким типом, операнд unsigned char оператора + повышается до int (при условии, что int может содержать все возможные значения в диапазоне unsigned char). Таким образом, если i == 255 и UCHAR_MAX == 255, то результатом сложения будет 256 и имеет тип (подписанный) int.

Присваивание неявно преобразует значение 256 из int обратно в unsigned char. Преобразование в беззнаковый тип четко определено; результат уменьшается по модулю MAX+1, где MAX - максимальное значение целевого беззнакового типа.

Если i был объявлен как unsigned int:

unsigned int i = UINT_MAX;
i++;

преобразования типов не будет, но семантика оператора + для беззнаковых типов также определяет модуль сокращения MAX+1.

Имейте в виду, что значение, присвоенное i, математически эквивалентно (i+1) % UCHAR_MAX. UCHAR_MAX обычно 255 и гарантированно не менее 255, но по закону может быть больше.

Может быть экзотическая система, в которой UCHAR_MAX тоже нельзя хранить в подписанном int объекте. Для этого потребуется UCHAR_MAX > INT_MAX, что означает, что в системе должно быть не менее 16-битных байтов. В такой системе продвижение будет с unsigned char до unsigned int. Окончательный результат будет таким же. Вы вряд ли встретите такую ​​систему. Я думаю, что есть реализации C для некоторых DSP с байтами больше 8 бит. Количество битов в байте определяется параметром CHAR_BIT, определенным в <limits.h>.

CHAR_BIT > 8 не обязательно означает UCHAR_MAX > INT_MAX. Например, у вас могут быть CHAR_BIT == 16 и sizeof (int) == 2, т.е. 16-битные байты и 32-битные ints).

Есть еще одна альтернатива, о которой не упоминалось, если вы не хотите использовать другой тип данных.

unsigned int i;
// ...
i = (i+1) & 0xFF; // 0xFF == 255

Это работает, потому что элемент modulo == 2^n, что означает, что диапазон будет [0, 2^n-1], и, таким образом, битовая маска легко сохранит значение в желаемом диапазоне. Возможно, этот метод будет не намного или менее эффективен, чем версия _4 _ / _ 5_, в зависимости от того, какую магию делает ваш компилятор за кулисами и как целевая система обрабатывает загрузки без слов (например, некоторые архитектуры RISC требуют дополнительных операции для загрузки значений, не превышающих размер слова). Это также предполагает, что ваш компилятор не обнаружит использование арифметики по модулю степени двойки для значений без знака и, конечно же, не заменит вам битовую маску, поскольку в подобных случаях использование модуля по модулю будет иметь большее семантическое значение (хотя с использованием этого как основа для вашего решения конечно не совсем портативная).

Преимущество этого метода заключается в том, что вы можете использовать его для степеней двойки, которые также не являются размером типа данных, например

i = (i+1) & 0x1FF; // i %= 512
i = (i+1) & 0x3FF; // i %= 1024
// etc.

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

Однако, вероятно, лучше всего оставить это, используя модуль по модулю, потому что код будет лучше понят другими людьми, обслуживающими код, и умный компилятор может в любом случае выполнять эту оптимизацию, что в первую очередь может сделать ее бессмысленной. К тому же разница в производительности, вероятно, будет настолько мала, что вообще не будет иметь значения.

Он будет работать, если количество бит, которые вы используете для представления числа, равно количеству бит в двоичном (беззнаковом) представлении (100000000) делителя -1, что в данном случае: 9-1 = 8 (char)