Vit (26.09.2010 23:42, просмотров: 147) ответил Т.Достоевский на Тоесть теоретически char это и есть длинна машинного слова? Во всяком случае в кейле прокатывает.
Не так. Типы данных относится к языку, компилятору и рядом. Языки ведь тоже разными бывают, как и диалекты. И нужно различать благие пожелания и необходимость. Для того, чтобы программа портировалась (необязательно оптимально) с минимумом напрягов из-за http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B9%D1%82
зоопарка типов, вводят типы, более-менее явно указывающие на собственно размерность типа, например, набор int8_t/uint8_t, int16_t/uint16_t, int32_t/uint32_t или с применением устоявшихся умолчаний - BYTE, WORD, DWORD. Хотя это, если глубже копнуть, определенного вида костыли. Именно Си в большинстве реализаций для МК должен уметь работать с 8-, 16-, 32-бит данными. Но для одного и того же камня в разных компиляторах, а то и в одном, но с разными опциями/библиотеками, размерность того же int может быть разной. И есть случаи, когда байт это не 8 бит. А вот что касается именно архитектуры кремния, то проблемы более не в неоптимальности использования памяти, в т.ч. при пересылках, - они разруливаются (явными указаниями), а скорее в вопросах обеспечения атомарности при оперировании данными "крупных" типов - это вылазит именно на меньшей разрядности. А как только идёт борьба за атомарность, начинается вписывание системных вещей типа критических секций, что ещё более разводит ветки и отдаляет от свободного портирования. При портировании в обратную сторону - свои проблемы подобного рода - например, выравнивание, борьба с которым часто заставляет использовать опции конкретного компилятора (потому как о них стандартизаторы и компиляторостроители нормально никак не договорятся). Так что если точно надо сэкономить - экономьте, но понимайте, что на 32-хбитниках оперирование с int8_t часто чуть дороже, чем с int32_t, хотя в осязаемом будущем программы на эти мелочи, например, можно будет плевать.