>[оверквотинг удален]
>> #define PRId32 "d" /* int32_t */
>> #define PRId64 "lld" /* int64_t */
> Отлично. Вы эти макросы в реальной жизни пробовали применять? Впрочем, вижу, пробовали:
>> printf("%" PRIdLEAST64, some_value) религия не позволяет?
> увы, религия не позволяет. Потому что:
> 1. такой способ записи подходит только в лабораторных условиях. _Читать_ (а наглядность
> - главное достоинство printf-like форматирования) подобный код - задача не для
> слабонервных. Попробуйте туда засунуть ещё пару целочисленных значений, да с какими-нибудь
> модификаторами для разнообразия, и результат показать здесь. А потом оценить количество
> людей, которым понравится портабельность _такой_ ценой.Этот вопрос не ставился. Был вопрос о реальности портабельности «родными» средствами языка. Это не говоря о том, что описываемые вами ситуации в рамках нормальной программы — редкость. Часто повторяющиеся *printf() выносятся в отдельные функции, и т.д. Впрочем, я могу не представлять себе какого-то проблемного класса программ — продемонстрируете?
> 2. от того, что я придумаю макрос PRIdLEAST64 там, где его нет,
> "стандартная для платформы" реализация printf не научится волшебным образом понимать эти
> самые 64битные значения.
Если «стандартная для платформы» реализация *printf не умеет понимать 64-битные значения (что, вообще говоря, нонсенс; пусть операции с 64-битными числами не будут атомарными, но они будут; впрочем, я не слишком большой спец в embedded-разработках), то и в программе не будет встречаться int64_t и иже с ним, так? Иначе ведь она всё равно на данной платформе даже не скомпилируется.
А если не будут встречаться 64-битные числа, то тогда используем макрос PRIdLEAST32... Ну и т.д.
> 3. в исходной задаче говорилось про size_t, off_t и int16_t. Случай int16_t
> разобрали выше. Для size_t и off_t, по факту, требуется {configure/compile}-time проверки
> с выбором между этими типами, и "обычными" int/long/etc там, где рантайм
> не в курсе POSIX'овых умностей. Опять же, см. пп.1 и 2.
Эм-м-м... Рантайм, он вообще, не в курсе size_t, off_t и так далее. Это чисто компиляторные заморочки. Оператор sizeof() ещё никто не отменял. Зачем делать выбор между типами size_t/off_t/etc. и int/long/etc., когда достаточно просто объявить size_t/off_t/etc. в случае их отсутствия (во время того же конфигурирования, или компиляции, например)?
> 4. Впереди ещё форматирование многобайтных строчек
А какое отношение имеют многобайтные строчки к размеру переменных? Для начала, какие у вас вообще строчки? char*? wchar_t*? А то вы всё пугаете, пугаете...
Стандартная библиотека предоставляет средства для форматирования строк в некоторых форматах. Если вам нужна экзотика — you're on your own, как в любой другой среде. Собственно, давно есть (портабельные, хе-хе) библиотеки для работы со специфическими кодировками, так что велосипед, опять же, изобретать не требуется...
> и непрямое (через *) указание аргументов.
И в чём здесь проблема? Не все платформы поддерживают? Ну простите... Возьмите тогда заодно точно так же BSD-шную реализацию *printf и таскайте с собой для таких случаев, в чём проблема-то? Не вижу серьёзных причин для того, чтобы всё с нуля переписывать.
>>>> Всего лишь заголовочный файл.
>>> П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий inttypes.h
>>> в вопросе форматирования сообщения fprintf'ом? Кое-кто здорово заменил исходную задачу
>>> той, с которой ему удобно сражаться, и понеслось...
>> Вы это серьёзно? Или вы в inttypes.h ни разу не заглядывали?
> Ну, макросов этих не помню, но, честно, они не помогают, см. возражения
> выше.
Они помогают, а единственное возражение было — «плохо читается». Хотя в общем случае я с этим аргументом согласен (удобочитаемость кода очень важна), всё же позволю себе заметить, что использование альтернативной системы для форматирования строк повышает сложность программы, что тоже не есть гуд.
> P.S. буквально в среду разглядывал реализации такого форматирования сначала в сысоевском
> коде, а потом в ещё одном проекте, претендующем на переносимость. И
> чего это люди не горят использовать стандартные механизмы в своих проектах
> ;)
Это их выбор, я их не спрашивал, вы, по всей видимости, тоже (иначе бы не вопрос задавали, а давали факты). Люди ещё пишут тысячи однотипных CMS на PHP, и эти CMS от своего количества лучше не становятся.
