LINUX.ORG.RU

История изменений

Исправление Crocodoom, (текущая версия) :

Я выше не видел условия про «горячий» код.

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

Если вас не волнуют такие мелочи, как эффективность регистровой утилизации и прочие HPC штучки, лучше взять другой язык, серьезно. Сишка всегда была про байто*бство.

И спор изначально был не uint16 vs uint32, а uint с конкретной разрядностью vs uint с неопределённой разрядностью.

Спор изначально был действительно об этом, но хрюндель упёрся рогом (пятачком?), что нет ничего плохого в том, что битность типа не матчится с битностью регистров. А я как раз и показываю, чем именно это плохо

Но всё чем обеспокоены эксперты с лорчика - потерей 2х бит при компиляции int8_t на архитектуру с 10 битами или генерацию 4 сложений вместо 1 для 32битного инта.

Исходная версия Crocodoom, :

Я выше не видел условия про «горячий» код.

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

Если вас не волнуют такие мелочи, как эффективность регистровой утилизации и прочие HPC штучки, лучше взять другой язык, серьезно. Сишка всегда была про байто*бство.

И спор изначально был не uint16 vs uint32, а uint с конкретной разрядностью vs uint с неопределённой разрядностью.

Спор изначально был действительно об этом, но хрюндель упёрся рогом (пятачком?), что нет ничего плохого в том, что битность типа не матчится с битностью регистров. А я как раз и показываю, чем именно это плохо