Здравствуйте, <Аноним>, Вы писали:
А>что на данный момент является стандартом С++ преобразования из wchar_t в char?
Пока только что только proposed wstring_convert
А>Например, вывести в поток ofstream строку wchar_t (не двоичным образом, а предврительным преобразованием в char).
Используя C, что входит в стандартную библиотеку C++:
int main()
{
using namespace std;
wstring ws = L"wide string";
//setlocale(LC_ALL, "russian");
ostream_iterator<char> osi(cout);
transform(ws.begin(), ws.end(), osi, wctob);
}
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, fk0, Вы писали: fk0>>у GCC представление о кодировке "строки" и L"строки" в корне принципиально разное. Первая никак не перекодируется при чтении файла (почему бы не взять кодировку из локали?) MC>Ага, и при компиляции на машинах с разными локалями будет получаться разный код.
Вот я и говорю, этот ваш GCC -- жалкая поделка финских студентов...
Здравствуйте, Аноним, Вы писали:
А>Подскажите, гуру, что на данный момент является стандартом С++ преобразования из wchar_t в char? А>Нарыл вагон примеров. Все работает, но мне надо для тестового задания точно знать, как ПРАВИЛЬНО и переносимо сделать преобразование. А>Например, вывести в поток ofstream строку wchar_t (не двоичным образом, а предврительным преобразованием в char). А>Заранее спасибо.
Уже не помню где, я находил следующий вариант преобразования:
Здравствуйте, gear nuke, Вы писали: GN>Коневерсия выполняется (как просили "предврительным преобразованием в char") функуией wctob в соответствии с кодовой страницей выбраной для текущей локали
А если локаль — utf8?
Здравствуйте, gear nuke, Вы писали: GN>Ровно как и wctob не будет конвертировать в более чем однобайтное представление.
Ну я на это и намекал.
Кстати, мне почему-то кажется, что с iconv будет проще, чем со всякими ортодоксатьными сиплюсплюсными потоками-шаблонами. Например, когда я последний раз интересовался, в бусте (в частности, xpressive) не было поддержки utf8 — и, мне кажется, это неспроста.
Здравствуйте, fk0, Вы писали: fk0> Если на G* начинается -- однозначно поделка. Православно только ISO/IEC.
Ну тогда -- однозначно трололо.
Стандарт перевода wchar_t в char
От:
Аноним
Дата:
09.02.10 07:33
Оценка:
Подскажите, гуру, что на данный момент является стандартом С++ преобразования из wchar_t в char?
Нарыл вагон примеров. Все работает, но мне надо для тестового задания точно знать, как ПРАВИЛЬНО и переносимо сделать преобразование.
Например, вывести в поток ofstream строку wchar_t (не двоичным образом, а предврительным преобразованием в char).
Заранее спасибо.
Здравствуйте, A_P, Вы писали:
A_P>Какая OS, какой компилятор? A_P>Какие библиотеки, сказали использовать?
Написано же всё:
переносимо сделать преобразование
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, <Аноним>, Вы писали:
А>>что на данный момент является стандартом С++ преобразования из wchar_t в char?
GN>Пока только что только proposed wstring_convert
А>>Например, вывести в поток ofstream строку wchar_t (не двоичным образом, а предврительным преобразованием в char).
GN>Используя C, что входит в стандартную библиотеку C++: GN>
Здравствуйте, alsemm, Вы писали:
A>И в какой кодировке будет вывод в osi? win1251? koi8r? или utf8?
Я не понял вопрос. Если выводить в файловый стрим, то ostream_iterator будет использовать
ofstream& operator<<(ofstream&, char);
который не выполняет коверсию.
Коневерсия выполняется (как просили "предврительным преобразованием в char") функуией wctob в соответствии с кодовой страницей выбраной для текущей локали
int main()
{
using namespace std;
wstring ws = L"wide строка.";
//setlocale(LC_ALL, ".1251"); // хз как получить кодовую стариницу, потому альтернатива ниже
locale::global(locale(".1251")); // кодировка для конверсии wctob
cout << cout.getloc().name() << '\n';
cout.imbue(locale()); // устанавливаем для стрима глобальную локаль, кодировка выбрана выше
cout << cout.getloc().name() << '\n';
cout.imbue(locale(".1252")); // не влияет на конверсию
cout << cout.getloc().name() << '\n';
ostream_iterator<char> osi(cout);
transform(ws.begin(), ws.end(), osi, wctob);
}
C
Russian_Russia.1251
Russian_Russia.1252
wide строка.
Поскольку в моём примере osi выводит на консоль, то она будет отображать используя локаль пользователя по умолчанию.
Или намекалось, что следует для конверсии использовать фасеты? Тогда на вопрос "как ПРАВИЛЬНО?" я скажу что надо читать документацию, что бы не напутать.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Mr.Cat, Вы писали:
MC>А если локаль — utf8?
Значит настало будущее, 0x год
Локаль несклько шире, чем кодовая страница, это набор фасетов. Кодовые страницы относятся к фасетам категории ctype. Текущий стандарт определяет 2 фасета, из которых конверсию выполняет только один — codecvt<wchar_t,char,mbstate_t>. Кодировки, для которых выполняется конверсия, зависят от реализации. В частности MSVC не поддерживает кодовые страницы utf-7 & utf-8. Ровно как и wctob не будет конвертировать в более чем однобайтное представление.
Если пройти по ссылке (из первого ответа) на proposal, то можно увидеть:
Say, for example, you have a code conversion facet called codecvt_utf8 that you want to use to output to cout a UTF-8 multibyte sequence corresponding to a wide string
то есть предполагается, что его надо где-то взять (с инструкциями к использованию).
Так же по той ссылке сказано:
Note that the Standard C++ library currently uses code conversion facets only within template class basic_filebuf, for converting from multibyte sequences when reading from a file and for converting to multibyte sequences when writing to a file
что намекает, что конверсия может выполняеться непосредственно при выводе в файл (но, как я понял вопрос, это не интересовало).
И, кстати, в исходном вопросе ничего про кодировки не сказано, о чём я намекал закомментированной строкой
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Аноним, Вы писали:
А>Подскажите, гуру, что на данный момент является стандартом С++ преобразования из wchar_t в char?
Про C++ не скажу. Там может что-то поверх C-шных интерфейсов быть. Не знаю.
Если вообще, то примерно это: http://www.unix.org/version2/whatsnew/mse.html
А>Нарыл вагон примеров. Все работает, но мне надо для тестового задания точно знать, как ПРАВИЛЬНО и переносимо сделать преобразование.
Вы таки определитесь, вам по стандарту (ISO, ГОСТ, IEEE, etc...) или под windows.
А>Например, вывести в поток ofstream строку wchar_t (не двоичным образом, а предврительным преобразованием в char).
Здравствуйте, puredev, Вы писали:
А>>>что на данный момент является стандартом С++ преобразования из wchar_t в char?
GN>> ostream_iterator<char> osi(cout); GN>> transform(ws.begin(), ws.end(), osi, wctob);
DESCRIPTION
The wctob() function tests whether the multi-byte representation of the
wide character c, starting in the initial state, consists of a single
byte. If so, it is returned as an unsigned char.
Never use this function. It cannot help you in writing international-
ized programs. Internationalized programs must never distinguish sin-
gle-byte and multi-byte characters.
Читайте маны, они рулез (C)
P>надеюсь прокатит
Нипракатило. mbstowcs таки прокатит. Но я бы потестировал везде, вроде как нигде кроме линуха
оно толком не работает вроде как.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
А>>что на данный момент является стандартом С++ преобразования из wchar_t в char?
GN>Используя C, что входит в стандартную библиотеку C++: GN>
#include <stdlib.h>
#include <stdio.h>
#include <locale.h>
#include <wchar.h>
int main()
{
const wchar_t *str = L"Превед мир.";
char buf[256];
int i;
setlocale(LC_ALL, "");
i=wcstombs(buf, str, sizeof(buf));
if (i<0) {
printf("wcstombs: can't convert in current locale.\n");
} else {
printf("wcstombs: %s\n", buf);
}
fputs("wctomb: ", stdout);
while (*str) {
i=wctob(*str++);
if (i>0) putchar(i);
}
putchar('\n');
return 0;
}
$ gcc -Wall test.c
$ locale |grep LC_CTYPE
LC_CTYPE=ru_RU.KOI8-R
$ ./a.out
wcstombs: Перевед мир.
wctomb: Перевед мир.
$ LC_ALL=ru_RU.UTF-8 ./a.out | iconv -f utf8
wcstombs: Перевед мир.
wctomb: .
В последней строке сущность говнокода проявлена.
С другой стороны, повторюсь, мне проверить сейчас негде, но я чуть менее чем уверен, что на разных вариантах BSD и Solaris будет хрен в 8-битных локалях. Возможно. В линуксе всё чотка. Что будет в виндах не знаю, но скорей вообще работать не будет, только если в cygwin, поэтому если говорить о переносимости, то скорей либо писать свои обёртки под разные платформы, либо пытаться реализовать для отдельных ущербных платформ собственные функции поддержки конверсии wchar_t как должно быть по стандарту.
Здравствуйте, fk0, Вы писали:
fk0>DESCRIPTION fk0> The wctob() function tests whether the multi-byte representation of the fk0> wide character c, starting in the initial state, consists of a single fk0> byte. If so, it is returned as an unsigned char.
fk0> Never use this function. It cannot help you in writing international- fk0> ized programs. Internationalized programs must never distinguish sin- fk0> gle-byte and multi-byte characters.
fk0> Читайте маны, они рулез (C)
rule — значит правило, стандарт. А маны привирают про возвращаемое значение. Нужна ли конверсия из wchar_t в char в "internationalized programs", или где-то ещё — с какой стати маны решают за пользователя, это так называемая свобода?
Description
The wctob function determines whether c corresponds to a member of the extended
character set whose multibyte character representation is a single byte when in the initial
shift state.
Returns
The wctob returns EOF if c does not correspond to a multibyte character with length
one in the initial shift state. Otherwise, it returns the single-byte representation of that
character as an unsigned char converted to an int.
fk0>mbstowcs таки прокатит. Но я бы потестировал везде, вроде как нигде кроме линуха fk0>оно толком не работает вроде как.
mbstowcs определена в стандарте С, при чём тут линух
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
fk0>>DESCRIPTION fk0>> The wctob() function tests whether the multi-byte representation of the fk0>> wide character c, starting in the initial state, consists of a single fk0>> byte. If so, it is returned as an unsigned char.
fk0>> Never use this function. It cannot help you in writing international- fk0>> ized programs. Internationalized programs must never distinguish sin- fk0>> gle-byte and multi-byte characters.
fk0>> Читайте маны, они рулез (C) GN>rule — значит правило, стандарт. А маны привирают про возвращаемое значение. Нужна ли конверсия из wchar_t в char в "internationalized programs", или где-то ещё — с какой стати маны решают за пользователя, это так называемая свобода?
Свобода -- это рабство. (C)
Маны какбе подсказывают и уберегают от говнокода. Жителям свободной страны конечно наплевать на internationalized characters, но неизвестно кто будет пользоваться их (говно)софтом.
fk0>>mbstowcs таки прокатит. Но я бы потестировал везде, вроде как нигде кроме линуха fk0>>оно толком не работает вроде как. GN>mbstowcs определена в стандарте С, при чём тут линух
Вообще я имел ввиду wcstombs. Линух при том, что только в егойной гнутой libc более-менее это всё работает. Мне и самому интересно знать где и как не работает. У freebsd или openbsd своя libc, у солярисов своя, у микрософта вообще чёрт ногу сломит. А "стандарту" не так уж много лет. И даже в линухе это может не работать в некоторых случаях (например, при несгенерированной локали, как я понимаю, фиг что будет).
Здравствуйте, fk0, Вы писали: fk0> Если он не интегрирован в libc штатно -- оно не более чем жалкая поделка финских студентов.
В glibc, по идее, есть. А вообще трололо.
Дык, сломай его.
fk0>$ gcc -Wall test.c fk0>$ locale |grep LC_CTYPE fk0>LC_CTYPE=ru_RU.KOI8-R fk0>$ ./a.out fk0>wcstombs: Перевед мир. fk0>wctomb: Перевед мир. fk0>$ LC_ALL=ru_RU.UTF-8 ./a.out | iconv -f utf8 fk0>wcstombs: Перевед мир. fk0>wctomb: . fk0>[/c]
fk0> В последней строке сущность говнокода проявлена.
То есть подменил строку для конверсии, установил вместо однобайтной локали мультибайтную и таким образом доказал? что многобайтный символ нельзя привести в 1 char
Можно еще с таким поэксперементировать
int main()
{
setlocale(LC_ALL, "");
wprintf(L"Перевед мир.");
printf("Перевед мир.");
}
MSVC такое нормально переварит кстати, без шаманств с -finput-charset и converting to execution character set: Illegal byte sequence. Однако не буду применять слово "говнокомпилер" к GCC, скажу что у меня руки не оттуда растут
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Mr.Cat, Вы писали:
GN>>Ровно как и wctob не будет конвертировать в более чем однобайтное представление. MC>Ну я на это и намекал.
Ээ... это только я понял, что под "преобразованием в char" подразумевается не "в последовательность char"?
MC>Кстати, мне почему-то кажется, что с iconv будет проще, чем со всякими ортодоксатьными сиплюсплюсными потоками-шаблонами.
Может быть даже не проще, а лучше, но это не Стандарт. utf-8 появится только в новом Стандарте, отсюда, наверное и отсутствие его в "в бусте (в частности, xpressive)".
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
потенциальное переполнение буфера.
fk0> Жителям свободной страны конечно наплевать на internationalized characters, но неизвестно кто будет пользоваться их (говно)софтом.
Открою секрет: не-православная-ОС нативно поддерживает эти самые "internationalized characters", поэтому мне и в голову не придёт хранить что то такое в char[] и заниматься конверсиями из пустого в порожнее, без особых на то причин.
fk0>И даже в линухе это может не работать в некоторых случаях (например, при несгенерированной локали, как я понимаю, фиг что будет).
То есть отвергнув одно, ты осознанно предложил полурешение
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
fk0>>$ LC_ALL=ru_RU.UTF-8 ./a.out | iconv -f utf8 fk0>>wcstombs: Перевед мир. fk0>>wctomb: . fk0>>[/c] fk0>> В последней строке сущность говнокода проявлена. GN>То есть подменил строку для конверсии, установил вместо однобайтной локали мультибайтную и таким образом доказал? что многобайтный символ нельзя привести в 1 char
Нормально -- это ортогонально к результату выдаваемому GCC?
Непонятно куда wprintf делаться будет, ибо там то место куда обязано поддерживать вывод wchar, а stdout в общем не поддерживает. Байт-ориентированный он. Как в него, спрашивается, 32-битные буквы записывать.
Пока писал абзац выше -- проверил. Таки выводит и в соответствии с локалью всё конвертирует. glibc 2.7. Пару лет назад где-то, на debian sarge или etch были проблемы и wprintf в файл фактически не работал. Возможно это как-то связано с fwide(), не скажу. Повторюсь, работает всё только в модных новых линухах, у остальных разброд и шатания.
И кстати применение wprintf ломает работу байт-ориентированных фуннкций вроде printf (просто не выводится). Не всё тут так хорошо...
GN> без шаманств с -finput-charset и converting to execution character set: Illegal byte sequence.
Опенсоурс так старался быть похожим на виндовс, так старался догнать микрософт, и в этой части, кажется, уже преуспел в этом: у GCC представление о кодировке "строки" и L"строки" в корне принципиально разное. Первая никак не перекодируется при чтении файла (почему бы не взять кодировку из локали?), вторая ожидается именно UTF-8. Микрософт в windows и outlook тоже использует 4 разных кодировки для русского языка...
Резюме такое: исходники держать только в UTF-8 (локаль при этом не мешает иметь KOI8, хотя местами может быть проблемно...) Оно, кстати, справедливо, ибо наткнуться на кодировку ещё можно в CVS/SVN и ещё десятке мест. И с юникодом все худо-бедно работают, а с перекодировками туда-сюда вряд ли.
GN> Однако не буду применять слово "говнокомпилер" к GCC, скажу что у меня руки не оттуда растут
В этом месте -- таки да. Но, см. выше. В этом даже есть позитив: что, спрашивается, ты будешь делать с KOI8 строками в исходнике и далее в бинарнике? Их на вывод перекодировать вот так просто -- никак, при чём KOI8 локаль может быть не сгенерирована попросту -- тогда вообще никак. С UTF-8 несколько веселее, потому что, по-дефолту UTF-8 локаль обычно есть и как я понимаю, в любой подходящей локали текст в итоге можно выдать путём двойного преобразования... в виду чего лучше таки использовать wchar... В общем нет места надписям на русском языке, в 8-битной кодировке, в исходнике.
Мой код писался какбе для демонстрации (не)работы wcstomb, а не как академический пример правильного программирования.
fk0>> Жителям свободной страны конечно наплевать на internationalized characters, но неизвестно кто будет пользоваться их (говно)софтом. GN>Открою секрет: не-православная-ОС нативно поддерживает эти самые "internationalized characters", поэтому мне и в голову не придёт хранить что то такое в char[] и заниматься конверсиями из пустого в порожнее, без особых на то причин.
В итоге они вообще не используют библиотеку C и задают здесь вопрос как сконвертить. Ага. И все функции там _A и _W на всякий случай. При чём из файла они всё равно читают _A и вынуждены как-то сконвертить. Этот секрет хорошо звучит только в маркетинге, до тех пор пока никто не знает как же оно там внутри устроено.
fk0>>И даже в линухе это может не работать в некоторых случаях (например, при несгенерированной локали, как я понимаю, фиг что будет). GN>То есть отвергнув одно, ты осознанно предложил полурешение
Ты вообще не решение предложил. В смысле не работающее для русского языка.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, fk0, Вы писали: fk0>> Если он не интегрирован в libc штатно -- оно не более чем жалкая поделка финских студентов. MC>В glibc, по идее, есть. А вообще трололо.
Если на G* начинается -- однозначно поделка. Православно только ISO/IEC.
Здравствуйте, fk0, Вы писали: fk0>у GCC представление о кодировке "строки" и L"строки" в корне принципиально разное. Первая никак не перекодируется при чтении файла (почему бы не взять кодировку из локали?)
Ага, и при компиляции на машинах с разными локалями будет получаться разный код.
где люди более толково донесли твою мысль
fk0> Пока писал абзац выше -- проверил. Таки выводит и в соответствии с локалью всё конвертирует.
Так и должно быть по стандарту происходит конверсия при выводе в стрим. Неужели в манах про это нет?
fk0>glibc 2.7. Пару лет назад где-то, на debian sarge или etch были проблемы и wprintf в файл фактически не работал. Возможно это как-то связано с fwide(), не скажу. Повторюсь, работает всё только в модных новых линухах, у остальных разброд и шатания.
В них C runtime реализован не полно.
fk0> И кстати применение wprintf ломает работу байт-ориентированных фуннкций вроде printf (просто не выводится). Не всё тут так хорошо...
Потому что стримы имеют оринтацию, т.н. byte-oriented и wide-oriented, устанавливается в зависимости от типа первой функции делающей ввод-вывод.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
потенциальное переполнение буфера.
fk0> Кстати ложь и провокация. Там есть не потенциальное, а практическое отсутствие терминирующего нуля (printf(buf)).
Ну '\0' то иногда будет дописываться
The wcstombs function converts a sequence of wide characters from the array pointed
to by pwcs into a sequence of corresponding multibyte characters that begins in the
initial shift state, and stores these multibyte characters into the array pointed to by s,
stopping if a multibyte character would exceed the limit of n total bytes or if a null
character is stored.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, SergeyT., Вы писали:
ST>Здравствуйте, Аноним, Вы писали:
А>>Подскажите, гуру, что на данный момент является стандартом С++ преобразования из wchar_t в char? А>>Нарыл вагон примеров. Все работает, но мне надо для тестового задания точно знать, как ПРАВИЛЬНО и переносимо сделать преобразование. А>>Например, вывести в поток ofstream строку wchar_t (не двоичным образом, а предврительным преобразованием в char). А>>Заранее спасибо.
ST>Уже не помню где, я находил следующий вариант преобразования:
Здравствуйте, SergeyT., Вы писали:
ST>Уже не помню где, я находил следующий вариант преобразования:
Имхо лучше такой способ не использовать, по крайней мере в направлении wchar_t -> char из-за проблемы с мультибайтностью
fk0 wrote:
> Вообще я имел ввиду wcstombs. Линух при том, что только в егойной гнутой > libc более-менее это всё работает. Мне и самому интересно знать где и > как не работает.
потенциальное переполнение буфера. fk0>> Кстати ложь и провокация. Там есть не потенциальное, а практическое отсутствие терминирующего нуля (printf(buf)). GN>Ну '\0' то иногда будет дописываться GN>
The wcstombs function converts a sequence of wide characters from the array pointed
GN>to by pwcs into a sequence of corresponding multibyte characters that begins in the
GN>initial shift state, and stores these multibyte characters into the array pointed to by s,
GN>stopping if a multibyte character would exceed the limit of n total bytes or if a null
GN>character is stored.
Ниасилел. В текущей локали.
fk0>> Пока писал абзац выше -- проверил. Таки выводит и в соответствии с локалью всё конвертирует.
Дадада.
GN>Так и должно быть по стандарту происходит конверсия при выводе в стрим. Неужели в манах про это нет?
Ойойой! Не факт. Не путать C++ и libc (без ++).
fk0>>glibc 2.7. Пару лет назад где-то, на debian sarge или etch были проблемы и wprintf в файл фактически не работал. Возможно это как-то связано с fwide(), не скажу. Повторюсь, работает всё только в модных новых линухах, у остальных разброд и шатания. GN>В них C runtime реализован не полно.
Да хоть как. Сам факт -- не работает!
fk0>> И кстати применение wprintf ломает работу байт-ориентированных фуннкций вроде printf (просто не выводится). Не всё тут так хорошо... GN>Потому что стримы имеют оринтацию, т.н. byte-oriented и wide-oriented, устанавливается в зависимости от типа первой функции делающей ввод-вывод.
Только fwide чо-та не памагаит. Я б поастерёгса использовать такие функции.
Здравствуйте, fk0, Вы писали: fk0> И кстати применение wprintf ломает работу байт-ориентированных фуннкций вроде printf (просто не выводится). Не всё тут так хорошо...
Глупость, ни чего не ломается, нужно просто "доработать напильником"
// set C/C++ locale
cout << "set system console locale..."
<< endl
<< "C locale: "
<< setlocale(LC_ALL, "")
<< endl;
locale::global(locale(""));
cout << "C++ locale: "
<< locale().name().c_str()
<< endl
<< endl;
//--------------------------------------------------------------------------
// set C++ stream locale
cout.imbue(locale());
clog.imbue(locale());
cerr.imbue(locale());
wcout.imbue(locale());
wclog.imbue(locale());
wcerr.imbue(locale());
//--------------------------------------------------------------------------
// don't sync. c and c++ streams
ios::sync_with_stdio(false);
//--------------------------------------------------------------------------
После этих "шаманств" вывод в консоль и char-строк и wchar_t-строк проблем не вызовет.