могу ли я всегда использовать uint8_t ? ведь оба беззнаковые и оба 8 бит.
и в программе вывода текста в UART uint8_t работает прекрасно.

char по умолчанию знаковый тип, более того его размерность заранее не известна...
Насчёт знаковости я погорячился, она тоже может меняться от реализации...
Его единственное назначение - это строки и символы. Для всего остального есть stdint.h.

Советую просто прочитать что стандарт говорит про это и посмотреть на то, что можно выиграть от 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. На то полиморфизм и нужен.

Ксения, расскажите, пожалуйста, про проигрыш? В чем он выражается конкретно? Я знаю и могу рассказать вам о выигрыше.

Вы смешали в кучу все, что только можно. char используется для того, о чем говорит его название: для хранения символов. Массивы charов - для последовательностей символов, т.е. строк. Строковые функции предназачены для работы со строками, поэтому будьте любезны передавать им указатель на char.

Если нужно работать со знаковыми или беззнаковыми числами и вы хотите их уложить в такой же размер памяти, какую занимает char - будьте добры использовать signed char или unsigned char. Для уменьшения писанины - объявленные в stdint.h типы int8_t и uint8_t. А вот если вы хотите с этими числами поработать как с символами используя строковые функции - то это явно нетрадиционное использование чисел и должно быть выделено явным преобразованием типа. И проблемы исчезнут, а программа станет читаемой и будет компилироваться без ошибок и предупреждений вне зависимости от того, как создатели компилятора представляют себе char по-умолчанию - знаковым или беззнаковым (имеют право!).

ИМХО - char всегда пишу если подразумевается строка или символ, всякие uint8 и прочая - для хранения данных в опрделенной размерности бит и указания знака, для переносимости проектов на разные целевые платформы.

у приличных людей строки это массивы wchar_t уже давно

я, например, предпочитаю char, в совсем сложных случаях добавляю signed, unsigned. ну не люблю я uint8_t и остальные типы с того инклуда
разницы никакой

-----

например для 55х тмсов (и наверняка для других странных архитектур) где char 16 бит стока надо переделывать в исходниках, что эта разница значения практически не имеет

Например что переделывать (конкретно)?
Я как раз-то и агитирую за использование по назначению типа char (только для строк и символов),
а то, что лично вы не используете типы из <stdint.h>, так это лично ваши предпочтения.
Мне очень нравится, к примеру, в небольших циклах использовать в качестве счётчика тип uint_fast8_t - получается оптимально и для кортексов, и для авр8, и для x86.
И переделывать ничего не надо. Если вы ещё не смогли оценить эту возможность - очень жаль.
Ну и насчёт wchar_t, вы тоже слегка преувеличиваете, так например в avr-gcc вообще как класс отсутствуют <wchar.h> и <wctype.h>,
а для работы с winapi TCHAR более уместен. Видите как оно бывает? Я бы сказал что в первую очередь от фреймворка стоит отталкиваться при выборе традиционных для него типов: в Qt одно в BCB другое в VS третье.

бывает и кроме win и авр-а программирование, не правда ли?

а использовать char или uint8_t - дело вкуса, я никаких претензий к пользователям stdint.h не предьявляю

по поводу архитектур с нестандартными размерами long, short, char и т.п. там кроме этого еще много всего нестандартного. ну и арифметика с указателями - да, ес-сно в ней ошибки

Несомненно. Полно и 8-ми и 16-ти разрядных архитектур, а сейчас и 64-ёх битники от ARM на подходе, так что всё только начинается
Конечно можно найти какие-либо нестандартные фишки при заточке компилятора под ту или иную архитектуру, но 99% программы можно и ИМХО нужно писать с прицелом на повторное использование на различных платформах. Чему и сопутствует <stdint.h>.
Вот и всё что я хотел сказать.

Самый рекордсмен по кривизне - это тип int
Что до stdint.h - их пользовать желательно там, где размер и поведение типов стандартизованы, говорили об этом тыщу раз.
Что такое "стандартизованное поведение"? А я и сам не знаю, допускаю только, что к typedef unsigned char uint8_t можно добавить еще какие-либо атрибуты, но до этого дело пока не дошло. И хорошо, неча мозг утомлять.
Ну и например какой-нить протокол связи, пакет которого описывается структурой. Совершенно очевидно, что для нормальной работы "и там и сям" надо пользоваться stdint.h а не всякой чепухой.

Во, вчера нарвался в исходниках v-usb:

И ни дай бог компилятор решит, что char по умолчанию беззнаковый...

можно этому верить?
Статья на Хабре

Чувак не вкуривает, для чего exact-width - типы нужны.

char по умолчанию не является ни знаковым, ни беззнаковым. Каким он будет, зависит от платформы. Это единственный тип, для которого наличие знака не определено стандартом. Сам попадал в неудобную ситуацию, когда char оказался знаковым.
Поэтому лучше всегда пользоваться типами с определенной размерностью stdint.h. Это избавит вас от проблем знаковости и некоторых проблем портируемости кода из-за разных размерностей типов на разных платформах. Мне попадался char = int = long размером 32 бит на одной из платформ.



Архитектур с нестандартными размерами long, short, char и т.п. мне еще не встречалось. Ибо в стандарте указано лишь соотношение long>= int >= char. Следовательно, размер long и char может совпадать.
Ошибки чаще всего не в компиляторах, а в программистах, которые не знают как средствами языка (например, stdint) пользоваться

Сообщение отредактировал Misile_Inc - Feb 20 2013, 08:32