Qraizer
Advanced Member | Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору ItsJustMe Цитата: Именно. Я-то думал, что раз Unicode, то все будет работать и без дополнительных ухищрений. А так, это то же самое, что юзать CharToOem, только не самому, а внутри wcout. | Ну, во-первых, твой исходник не юникодовой, а ансишный. Попробуй комплятору скормить .cpp в юникоде. Я знаю только один компилятор, который понимает разные кодировки исходников, кроме стандартного ASCII-8. И это MSный. Поэтому, когда компилятор встречает в программе L-литералы или строки, он не обязан (в твоём понимании, ибо он не телепат) правильно переводить символы, чьи значения находятся в диапазоне 128-255, в адекватные юникодные. Во-вторых, консоль по-дефолту тоже не юникодная, и поэтому символы будут претерпевать преобразования также и при вводе-выводе. Поэтому её тоже надо настроить. Если пишешь не консольное, а GUIное приложение, то эта проблема не встаёт. В-третьих, CharToOem() внутри std::wcout - это далеко не одно и то же, что у тебя в программе. По меньшей мере, это удобнее, потому как после std::basic_ios<>::imbue() просто взял и забыл о проблемах с перекодировками, вместо того, чтобы постоянно дёргаться этой CharToOem(), соответственно и массивом для неё, а потом ещё всплывут проблемы с разделением этого массива между потоками... Бр... Но есть ещё две, если не больше, причины: std::wcout никогда не столкнётся с ошибкой переполнения буфера и всегда будет использовать для перекодирования оптимизированные алгоритмы, если, конечно авторы библиотек не подведут. В общем-то, этими "ухищрениями" проблемы разработки юникодовых приложений по большому счёту и ограничиваются. Так что имеет смысл платить эту малую стоимость за возможность писать многоязычные приложения. Если когда-нибудь пытался делать это, используя простой "мультибайт", то оценишь. Кроме того, юникодовые приложения под NTями работают быстрее ансишных.
---------- Одни с годами умнеют, другие становятся старше. |
|