Цитата(Genadi Zawidowski @ Jan 19 2013, 03:49)
... и посмотреть на то, что можно выиграть от uint_fast8_t, например (на проектах, переносимых между ARM и AVR).
Много тут не выиграешь, а скорее проиграешь.
Тип char крепко прижился в языке, т.к. на него все стринги завязаны, то бишь текстовые строки. Совсем обойтись без строковых сообщений сложно, а если их использовать, то окажется, что все строковые аргументы у библиотечных функций объявлены именно как char, а не иначе. Самим же написать что-то типа форматного printf'а слабО. А форматная печать (когда текст перемежается с цифирью) нужна бывает очень часто. А каждый раз сращивать такую строку из кусочков текста и чисел утомительно.
Конечно, буквам все равно где лежать, в char'ах или uint8_t'ах, однако строковые функции хотят только char, а всякий раз явно переопределять тип аргументов накладно.
Возможно из-за этого многие ... не пользуются ни тем, ни другим
, а выдумывают свои обозначения типов, отсутствующие в стандарте языка, которые с помощью дефайна (#define) определяют в заголовке программы должным образом. Чаще всего это типы:
i8, i16, i32
и их беззнаковые аналоги:
u8, u16, u32
Поэтому при переходах с одной архитектуры на другую, бывает достаточно только переопределить эти самодельные типы, не производя правку в алгоритмах. А то после того, как в некоторых архитектурах char стал двухбайтым, положиться стало не на что. И тут проявляет себя слабая сторона языка C/C++, когда типы переменных определены не строго, а в зависимости от архитектуры процессора. Эта особенность полезна, чтобы использовать язык, как кроссассемблер, но вредна, когда ставит работу алгоритмов в зависимость от этого.
Впрочем, проблему взаимодействия со стриговыми функциями этот метод не решает. Но если это C++, то всегда можно доопределить аналоги стринговых функций, с готовностью пожирающие аргументы типа i8 и u8 вместо char. На то полиморфизм и нужен.
в чем отличие uint8_t от char?
Jan 18 2013, 11:14
