Здравствуйте, pepsicoca, Вы писали:
P>Ну не до такой же степени. Вдумайтесь — Юникод специально был создан, чтобы не переключать локали. И вот после всего этого, чтобы вывести Юникодный символ нужно явно указать локаль? Зачем тогда Юникод было городить?

Юникод не был создан, чтобы "не переключать локали". Стандарты юникода были придуманы для создание единой «широкой» кодировки. При этом технически системе, чтобы уметь рисовать символы из определённого диапазона символов юникода (например кириллицу), необходимо иметь соответствующую локаль. При этом для разработчиков прикладного ПО важно просто использовать широкие символы, а то, будут ли они отображаться и как — перекладывается на плечи системы и пользователя, эту систему конфигурирующему: т.е. если приложение работает с испанским, французским, немецкими, русским и китайским языками, то оно просто использует широкие символы (UTF-16) внутри своих алгоритмов (ну или UTF-8 например), в то время как пользователь, ставящий такую софтину должен позаботиться о наличии испанской, французской, немецкой, русской и китайской локализации у себя в системе, иначе рискует ничего не увидеть или увидеть "квадратики" и прочие кракозябры. Вот ты возьми скачай китайскую юникодную софтину и проинсталь у себя и поделись с нами впечатлениями: у тебя же не стоит китайская локаль в системе, правда? Плюс, как теюе тут верно заметили, есть программы, не использующие юникод, для таких тоже есть свои настройки в системе: использование определённой локали. Если юникодной софтине достаточно просто наличие локали в системе, то неюникодную надо носом тыкать, мол юзай вот эту. Ну и консоль виндовая, походу неюникодная.




P>Там уже никто не читает.
Да ладно. Я читаю.




P>Это верно для std::ofstream. Для std::wofstream ожидаемое поведение не такое. Очевидно, что если std::ofstream работает с файлом как с последовательностью байт char, то std::wofstream должен работать с файлом как с последовательностью широких байт wchar_t.

Ничё он не должен: файл как был последовательностью байт, так таковой и остался, и завтра таким же будет. Поэтому если вы ожидаете от std::wofstream такого поведения, это вовсе не означает что он должен это делать так. Я вот ничего такого от него не ожидаю, я ожидаю от него только лишь стандартного поведения. А стандарт С++ заботится о переносимости стандартной С++ библиотеки между платформами.

Файл — это поток байт! Не важно что там за данные: текст в кодировке UTF-32, xml в кодировке UTF-8 или видеопоток MPEG4, файл остаётся последовательностью байт. Всегда! И если в файле не однобайтовый текст, а некие другие данные, то прикладному ПО надо эти данные прочитать и раскодировать в нужное представление в памяти. Текст в UTF-32 — это тоже "другие данные"! Если в файле на самом деле лежит текст в кодировке UTF-16, тогда этот поток байт надо правильно представить в памяти, для этого существуют библиотеки подобные libiconv или поддержка на уровне API операционной системы. Ещё раз: такое поведение стандартно и переносимо между всем чем только угодно. Если необходимо изменить это стандартное поведение — надо настраивать файловые потоки специальным образом. Точка.




P.S.: Видели фильм "День Независимости" c певцом-нигером в главной роли? Так вот возможность заразить нашей вируснёй инопланетные компы существовала именно благодаря тому что std::basic_ostream</*пофиг char или wchar_t*/> писал всё в файл не двубайтами, а только байтами, байтами, байтами ...

... шутка конечно: переносимость поведения std::basic_ostream<> зиждется только на том, что на всех возможных системах файл — есть последовательность байт, а байт — равен восьми битам, а бит может принимать только два состояния [on] и [off]. Если прилетит межгалактический корабль с пришельцами, которого их бит будет иметь три состояния [on] [median] [off], а байт состоять из 16 битов, то их, инопланетный std::basic_ostream<> будет несовместим с нашим std::basic_ostream<>, чтоб их совместить, придётся фасет специальный напедалить!