Переносимый printf

а давно printf из стандартной библиотеки перестал быть переносимым ?

http://www.boost.org/doc/libs/1_47_0/libs/format/doc/format.html
оно?

> а давно printf из стандартной библиотеки перестал быть переносимым ?
С тех пор как повился второй по счету компилятор =)

Если интересно, примеры:
vsnprintf [gcc], _vsnprintf [msvc] - разное поведение
vsnprintf [char], vswprintf [wchar] - разное возвращаемое значение
_vscprintf [mcvc only]
wprintf [gcc], wprintf [msvc] - разная интерпритация %s

И т.д. Из-за чего приходится писать много оберток.
Видел много проектов (например jabberd2 или из списка по ссылке в топике), которые тащат свою реализацию, но удовлетворительной пока не нашел.

нет, нужен си и интерфейс, совместимый со стандартным printf
хотя сам по себе boost.format вещь хорошая

дык, не используй нестандартные разширения и проблем не будет

Если интересно, примеры: [..]

сравнение не совсем корректное: ms'у законы не писаны, т.ч. там всё что хочеш может быть. char/wchar — разные типы, разные функции.

Пример проблемы?

wprintf(L"hello %s", "world");

Или

int bufsiz = vsnprintf(buff, size, fmt);
#ifdef GCC
if (bufsiz > size)
    buff = malloc(bufsiz);
#elsif MSVC
if (bufsiz == -1)
    buff = malloc(_vscprintf(fmt));
#endif

И т.п.

от wchar'а геморроя больше чем пользы, поэтому про функции с w можно сразу забыть

> сравнение не совсем корректное: ms'у законы не писаны
Поэтому самое правильное решение - использовать переносимую реализацию вместо их.

> от wchar'а геморроя больше чем пользы
Как и в других плохих вещах, в wchar возникает необходимость из-за винды.

Как раз из-за венды мысли о wchar'е должны были бы сразу пропасть, ибо размеры его в венде и в линухе разные. Я вообще еще ни разу не встречал ни одного серьезного коммерческого проекта в котором использовали бы wchar.

> cat test.c
#include <stdio.h>
#include <wchar.h>

int main()
{
wprintf(L"hello %s\n", «world»);
return 0;
}

gcc test.c -o test

./test

hello world


что, собственно, я сделал не так?

В 99.99% случаев проверять код возврата этих функций не нужно. Переаллокация памяти в случае если в буфер что-то не влезло выглядит страшно.

> что, собственно, я сделал не так?
Никто не винит ув. анонимуса в том, что в Visual C++ реализация такая: http://msdn.microsoft.com/en-us/library/hf4y5e3w%28v=vs.80%29.aspx

When used with printf functions, specifies a single-byte–character string; when used with wprintf functions, specifies a wide-character string.

Characters are printed up to the first null character or until the precision value is reached.

Не читали тред?

Я вообще еще ни разу не встречал ни одного серьезного коммерческого проекта в котором использовали бы wchar.

ядро WINDOWS NT ? полностью на wchar_t

не видел его сорцов, но в ms и не такие извраты случаются

> Я вообще еще ни разу не встречал ни одного серьезного коммерческого проекта в котором использовали бы wchar.

Разве в винде не определяют _UNICODE в 90% приложений? Вместо этого каждый раз перекодируют строки в UTF16 перед передачей в WinAPI?

Переаллокация памяти в случае если в буфер что-то не влезло выглядит страшно.

Ну, это, очевидно, зависит от конкретного случая.

Разве в винде не определяют _UNICODE в 90% приложений? Вместо этого каждый раз перекодируют строки в UTF16 перед передачей в WinAPI?

Если пишут кроссплатформенно, то такими извратами не страдают. Обычно используется char * с utf-8 и какая-нибудь кроссплатформенная обвязка, чтобы напрямую не работать с winapi.

(CL-USER:FORMAT)

Иногда этого хватает, но в случае, когда из-за этого постоянно приходится конвертировать строки, только чтобы хранить их в u8, а не u16, лучше просто хранить их в u16.
Если не определен _UNICODE, лего забыть конвертнуть строку перед вызовом winapi и получить багу.

Те же boost.filesystem и qt - примеры обвязок - используют wchar_t (первый - только в винде).

так как ядро WINDOWS NT юникодное и использует wchar_t то если в проекте не определен макрос UNICODE вызываются переходники с суффиксами A например #ifdef UNICODE #define SetWindowText SetWindowTextW #else #define SetWindowText SetWindowTextA #endif

это реально экспортируемые функции их задача очень проста сконвертить строки в wchar_t и вызвать W (SetWindowTextW) версии поэтому под вендой просто не выгодно юзать не wchar_t потому что тем самым мы напрягаем дополнительный код конвертить при каждом вызове строки в UNICODE

так как ядро WINDOWS NT юникодное и использует wchar_t то если в проекте не определен макрос UNICODE вызываются переходники с суффиксами A например

#ifdef UNICODE
#define SetWindowText SetWindowTextW
#else
#define SetWindowText SetWindowTextA
#endif

Основное ограничение, что версии *A не поддерживают нормально utf8, только всякие cp1251.

Те же boost.filesystem и qt - примеры обвязок - используют wchar_t (первый - только в винде).

что они там используют внутри никого не волнует, главное, что наружу торчит человеческий интерфейс без всяких wchar_t

С wchar_t :)

См. boost::filesystem::path::value_type
Но, да, при этом path умеетв конвертировать свои аргументы char -> wchar, так что я не прав

Ха! Не думал, что наткнусь-таки сам - оказывается для таких случаев есть gnulib.

И еще ссылка по теме, может кому пригодится: http://www.jhweiss.de/software/snprintf.html

В Qt вообще QString/QChar, где ты там wchar_t нашел?

>Если пишут кроссплатформенно, то такими извратами не страдают. Обычно используется char * с utf-8 и какая-нибудь кроссплатформенная обвязка, чтобы напрямую не работать с winapi.

Все COM-овские строки по определению wide, например. Строки в jni и P/Invoke под виндой тоже wide.

> В Qt вообще QString/QChar, где ты там wchar_t нашел?
The QChar class provides a 16-bit Unicode character. wchar_t нету, да.

Ну дык нету, да. (В винде wchar_t - 16 битный, в линуксе - 32 битный)