Предупреждение о конверсии с шагом [дубликат]

float, short и char рассматриваются стандартным типом «типов хранения», то есть субдиапазонами, которые вы можете использовать для сохранения некоторого пространства, но которые не собираются покупать вам какую-либо скорость, потому что их размер «неестественен» для CPU.

На некоторых процессорах это неверно, но хорошие компиляторы достаточно умны, чтобы заметить, что если вы, например, добавьте константу в unsigned char и сохраните результат обратно в unsigned char, тогда нет необходимости проходить через преобразование unsigned char -> int. Например, с g ++ код, сгенерированный для внутреннего цикла

void incbuf(unsigned char *buf, int size) {
    for (int i=0; i<size; i++) {
        buf[i] = buf[i] + 1;
    }
}

, является просто

.L3:
    addb    $1, (%rdi,%rax)
    addq    $1, %rax
    cmpl    %eax, %esi
    jg  .L3
.L1:

, где вы можете видеть, что команда беззнакового добавления сложения (addb) Используется.

То же самое происходит, если вы выполняете вычисления между короткими int и сохраняете результат в коротких int.

Связанный вопрос, похоже, очень хорошо его охватывает: CPU просто нет. 32-разрядный процессор имеет свои собственные арифметические операции, настроенные для 32-разрядных регистров. Процессор предпочитает работать в своем любимом размере, и для таких операций копирование небольшого значения в регистр собственного размера дешево. (Для архитектуры x86 32-разрядные регистры названы так, как если бы они были расширенными версиями 16-разрядных регистров (eax - ax, ebx - bx и т. Д.), См. x86 целочисленные инструкции ).

Для некоторых чрезвычайно распространенных операций, в частности векторной / float-арифметики, могут быть специализированные инструкции, которые работают с другим типом или размером регистра. Для чего-то вроде короткого, заполнение (до) 16 бит нулей имеет очень небольшую стоимость исполнения и добавление специализированных инструкций, вероятно, не стоит времени или места на уме (если вы хотите получить действительно физическое о том, почему, я не уверен, что они будут занимать реальное пространство, но он становится более сложным).

Это не особенность языка, так как это ограничение физических процессорных архитектур, на которых выполняется код. Экран int в C обычно является размером вашего стандартного регистра CPU. Больше кремния занимает больше места и больше мощности, поэтому во многих случаях арифметику можно выполнять только по типам «натурального размера». Это не универсально, но большинство архитектур все еще имеют это ограничение. Другими словами, при добавлении двух 8-битных чисел то, что на самом деле происходит в процессоре, это тип 32-разрядной арифметики, за которой следует либо простая битовая маска, либо другое подходящее преобразование типа.