LINUX.ORG.RU

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

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

не «надеется, что влезет», он точно знает, сколько у него бит на шине, в каком порядке расположены биты и байты в памяти и прочее

То-то и оно. И раз уж мы выяснили, что проекты как правило пишутся под конкретные системы. То фактически каждый раз программист выбирает тип на основе того, сколько бит ему нужно. Он знает, сколько в данном случае бит скажем у int или char. На системе, где данные типы имеют другую битность (в смысле количество бит в типе) будет выбран при прочих равных уже другой тип. Т.е. я к тому, что даже сейчас, даже использую типы char/int/long и т.п. мы все равно выбираем типы на основе битности, просто в каждом случае мы смотрим, сколько бит у типа в целевой системе/компиляторе. Так и что плохого в том, чтобы у типов было жестко указано количество бит? Что в целом и сделали в C++ сделав надстройку над фундаментальными типами в виде int8_t, int16_t и т.п.

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

не «надеется, что влезет», он точно знает, сколько у него бит на шине, в каком порядке расположены биты и байты в памяти и прочее

То-то и оно. И раз уж мы выяснили, что проекты как правило пишутся под конкретные системы. То фактически каждый раз программист выбирает тип на основе того, сколько бит ему нужно. Он знает, сколько в данном случае бит скажем у int или char. На системе, где данные типы имеют другую битность (в смысле количество бит в типе) будет выбран при прочих равных уже другой тип с такой же битностью. Т.е. я к тому, что даже сейчас, даже использую типы char/int/long и т.п. мы все равно выбираем типы на основе битности, просто в каждом случае мы смотрим, сколько бит у типа в целевой системе/компиляторе. Так и что плохого в том, чтобы у типов было жестко указано количество бит? Что в целом и сделали в C++ сделав надстройку над фундаментальными типами в виде int8_t, int16_t и т.п.