Здравствуйте, pepsicoca, Вы писали:

P>Так тоже не работает. Может у меня винда битая? Винда не переставлялась лет пять, но у нас довольно сильный IT отдел и в винде стоят все апдейты по самое немогу. Может какой-то апдейт отрубил wcout?

Если действительно хочешь чему-то научиться, то как минимум на год выкинь из головы даже мысль о том, что в твоих проблемах виноват кто-то, кроме тебя. Я серьезно говорю.

Здравствуйте, Аноним, Вы писали:

А>

А>#include <iostream.h>

А>void main(){
А>std::wcout<<L"hello\n\r";
А>}
А>

std::wcout<<L"hello\n\r" << std::endl;

endl кроме перевода строки еще и буфер опорожняет.

Здравствуйте, catBasilio, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

А>>

А>>#include <iostream.h>

А>>void main(){
А>>std::wcout<<L"hello\n\r";
А>>}
А>>

B>

B>std::wcout<<L"hello\n\r" << std::endl;
B>

B>endl кроме перевода строки еще и буфер опорожняет.

Так тоже не работает. Может у меня винда битая? Винда не переставлялась лет пять, но у нас довольно сильный IT отдел и в винде стоят все апдейты по самое немогу. Может какой-то апдейт отрубил wcout? Кроме этого в винде вроде все работает и даже не особенно часто она виснет. Было у кого-то что-то подобное?

Спасибо

Добрый день.

Есть BCB60. Есть Win2000. И есть такой код:

#include <iostream.h>

void main(){
std::wcout<<L"hello\n\r";
}

Этот код компилится, линкуется, выполняется, но ничего не печатает .

Вопрос:

1. Как вывести хотя бы английское сообщение в Юникоде в стандартный поток в Win2000?

Спасибо

Здравствуйте, catBasilio, Вы писали:

B>endl кроме перевода строки еще и буфер опорожняет.
Разве в деструкторе не должен быть сброс буфера? По-моему, должен.

Здравствуйте, Аноним, Вы писали:
А>Этот код компилится, линкуется, выполняется, но ничего не печатает :-(.

wcout.imbue(std::locale("rus_rus.866"));

Здравствуйте, Аноним, Вы писали:
А>Этот код компилится, линкуется, выполняется, но ничего не печатает :-(.

int _tmain(int argc, _TCHAR* argv[])
{
    std::string localeName = std::locale("").name();
    setlocale(LC_ALL, localeName.c_str());
    std::cout << "Using console locale: " << localeName << std::endl;

    std::wcout.imbue(std::locale(localeName.c_str()));
    std::wcout << L"Хачу чаю аж кончаю!!!" << std::endl;

    return 0;
}

Здравствуйте, Аноним, Вы писали:

А>Добрый день.

А>Есть BCB60. Есть Win2000. И есть такой код:


А>

А>#include <iostream.h>

А>void main(){
А>std::wcout<<L"hello\n\r";
А>}
А>

А>Этот код компилится, линкуется, выполняется, но ничего не печатает .

А>Вопрос:

А>1. Как вывести хотя бы английское сообщение в Юникоде в стандартный поток в Win2000?

А>Спасибо
А что шестерка держит юникод?

Аноним 1 пишет:

> Этот код компилится, линкуется, выполняется, но ничего не печатает .

Оно наверняка печатает, только консоль это не отображает.

Тебе нужно консоль в UCS-2 для этого иметь, и в ней программу свою
запускать.

я не знаю, есть ли в винде консоль с поддержкой UCS-2 .
Возможно, можно в стандартной консоли поставить какую-то
кодировку через

chcp

pepsicoca пишет:

> B>std::wcout<<L"hello\n\r" << *std::endl*;
> B>
>
>
>
> B>endl кроме перевода строки еще и буфер опорожняет.
>
> Так тоже не работает. Может у меня винда битая? Винда не переставлялась

По выходу из приложения удаляется объект std::wcout, вызывается
его деструктор, закрывается поток, и буфера опорожняются.

Так что тут std::endl или flush звать не обязательно,
ничего не изменится.

Здравствуйте, Alca, Вы писали:

A>А что шестерка держит юникод?

Судя по тому, что это линкуется, должна держать.

Здравствуйте, Rakafon, Вы писали:

R>Здравствуйте, Аноним, Вы писали:
А>>Этот код компилится, линкуется, выполняется, но ничего не печатает .

R>

R>int _tmain(int argc, _TCHAR* argv[])
R>{
R>    std::string localeName = std::locale("").name();
R>    setlocale(LC_ALL, localeName.c_str());
R>    std::cout << "Using console locale: " << localeName << std::endl;

R>    std::wcout.imbue(std::locale(localeName.c_str()));
R>    std::wcout << L"Хачу чаю аж кончаю!!!" << std::endl;

R>    return 0;
R>}
R>

Это тоже не работает. И предыдущий пример с wcout.imbue(std::locale("rus_rus.866"));

тоже не работает. То есть std::cout выводит сообщение, а std::wcout ничего не выводит.

Может есть какой-то секретный флаг в компиляторе? Или в опциях что-то включить/выключить надо?

Здравствуйте, catBasilio, Вы писали:

А>>

А>>#include <iostream.h>

А>>void main(){
А>>std::wcout<<L"hello\n\r";
А>>}
А>>

B>

B>std::wcout<<L"hello\n\r" << std::endl;
B>

B>endl кроме перевода строки еще и буфер опорожняет.

Что ещё за новость? Тогда писать надо так:

int main()
{ 
    std::wcout<<L"hello\n\r";
    //...куча другого вывода
    std::wcout << flush;//для надёжности обернуть в RAII.
    return 0;
}

Только никто так не пишет. Буфер можно скинуть предварительно. Но в конце программы он будет скинуть автоматически.

Здравствуйте, Аноним, Вы писали:

А>Добрый день.

А>Есть BCB60. Есть Win2000. И есть такой код:


А>

А>#include <iostream.h>

А>void main(){
А>std::wcout<<L"hello\n\r";
А>}
А>

А>Этот код компилится, линкуется, выполняется, но ничего не печатает .

А>Вопрос:

А>1. Как вывести хотя бы английское сообщение в Юникоде в стандартный поток в Win2000?

А>Спасибо

Попробовал тот же самый код под WinXP на том же самом BCB60. Тот же самый эффект — Юникод не печатает. Приложение создается как виндовское консольное. Может надо что-то включить в консоли?

P>Попробовал тот же самый код под WinXP на том же самом BCB60. Тот же самый эффект — Юникод не печатает. Приложение создается как виндовское консольное. Может надо что-то включить в консоли?

Значит BCB у тебя такой хороший! У меня вот MS VC++ 9.0 прекрасно всё делает!

Здравствуйте, Rakafon, Вы писали:

P>>Попробовал тот же самый код под WinXP на том же самом BCB60. Тот же самый эффект — Юникод не печатает. Приложение создается как виндовское консольное. Может надо что-то включить в консоли?

R>Значит BCB у тебя такой хороший! У меня вот MS VC++ 9.0 прекрасно всё делает!
R>

Действительно, в MSVC этот код работает. Хотя у меня старая студия — 2003 года.

Здравствуйте, pepsicoca, Вы писали:

P>Действительно, в MSVC этот код работает. Хотя у меня старая студия — 2003 года.

Я нашёл для себя только один надёжный способ писать напрямую UCS-2 — через WriteConsoleW

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

Здравствуйте, Мишень-сан, Вы писали:

МС>Я нашёл для себя только один надёжный способ писать напрямую UCS-2 — через WriteConsoleW

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

Действительно, в BCB60 WriteConsoleW работает. И без всякого предварительного imbue.

Здравствуйте, pepsicoca, Вы писали:
P>Действительно, в BCB60 WriteConsoleW работает. И без всякого предварительного imbue.

Действительно! А почему бы этому "мегарешению" не заработать без imbue? Ведь imbue — это метод задания локального контекста потоковым класса С++,а в случае cout/wcout — задания локали стандартному потоку вывода С++ (который, как вы наверное знаете, может быть перенаправлен из консоли в файл например, + работа с stdout и stdin — это переносимо не только между Windows98 и WindowsXP, но и между другими платформами); вы же работаете с хэндлом консольного окна, т.е. напрямую пишете в буфер консольного окна и никакого отношения к работе со стандартными потоками С++ это не имеет, следовательно вообще вопрос не по С++, а по WinAPI!

P.S.: ... пишу в консоль, используя хэндл консольного окна:

Здравствуйте, Rakafon, Вы писали:

R>Здравствуйте, pepsicoca, Вы писали:
P>>Действительно, в BCB60 WriteConsoleW работает. И без всякого предварительного imbue.

R>Действительно! А почему бы этому "мегарешению" не заработать без imbue? Ведь imbue — это метод задания локального контекста потоковым класса С++,а в случае cout/wcout — задания локали стандартному потоку вывода С++ (который, как вы наверное знаете, может быть перенаправлен из консоли в файл например, + работа с stdout и stdin — это переносимо не только между Windows98 и WindowsXP, но и между другими платформами); вы же работаете с хэндлом консольного окна, т.е. напрямую пишете в буфер консольного окна и никакого отношения к работе со стандартными потоками С++ это не имеет, следовательно вообще вопрос не по С++, а по WinAPI!

R>P.S.: ... пишу в консоль, используя хэндл консольного окна:

R>

Вот это мне как раз и непонятно. На то и Юникод, чтобы забыть о переключении таблиц символов. Если есть Юникодная строка, зачем мне указывать локаль для потока? Код Юникодного символа ОДНОЗНАЧНО определяет его начертание и принадлежность к тому или иному алфавиту. Зачем еще указывать локаль? Если текущий код это китайский иероглиф — пусть система напечатает китайский иероглиф. Если текущий код это греческая буква "кси" — пусть система напечатает греческую букву "кси". При чем тут локаль — совершенно непонятно.

Здравствуйте, pepsicoca, Вы писали:

P>Вот это мне как раз и непонятно. На то и Юникод, чтобы забыть о переключении таблиц символов. Если есть Юникодная строка, зачем мне указывать локаль для потока? Код Юникодного символа ОДНОЗНАЧНО определяет его начертание и принадлежность к тому или иному алфавиту. Зачем еще указывать локаль? Если текущий код это китайский иероглиф — пусть система напечатает китайский иероглиф. Если текущий код это греческая буква "кси" — пусть система напечатает греческую букву "кси". При чем тут локаль — совершенно непонятно.

Во-первых: Юникод — это всего лишь соглашение, что такой-то китайский иероглиф имеет такой-то цифровой код. СОГЛАШЕНИЕ! А вот реализации юникода бывают разные. Это примерно, как CORBA — есть набор спецификаций, а вот реализаций этой корбы дофигищща, причёи ни одна не имплементит спецификации корбы на сто процентов. Так же и с Юникодом. Например кодировка UTF-8 предполагает, что в последовательности байт каждый символ может занимать место от 1 до 6 байт, UTF-16 — от 2 до 6, при этом есть UTF-16BE и UTF-16LE, различающиеся порядком бит в байте, есть ещё UTF-32, и так далее и тому подобное. Например в операционных системах Windows, которые называют себя юникодными начитная с NT ядра, на уровне Win32API идёт поддержка кодировки USC-2LE, которая подразумевает, что каждый символ в последовательности байт занимает 2 байта, не более и не менее. Соответственно используя USC-2LE просто физически невозможно начертить полностью все плоскости символов Юникода. Поэтому если некая софтина собирается у себя в окне писать похабщину всякую на языке 300 лет назад вымершего племени африканских попуасов, то соответственно должна предоставить соответствующий шрифт и соотвествующие алгоритмы работы с этим шрифтом и механизмы его рисования у себя в окошке, потому что взять и просто тупо подсунуть эту бяку функции TextOut() например не получится. Полноценную реализацию Юникода UTF-16 винда стала поддерживать только то ли с 2000-ной винды то ли начиная с XP. Однако это, самом собой не гарантирует корректного начертания корейской хангыли без установленной в системе соответствующей локали. Впрочем, что мне рассказывать вам про Юникод, смотрите сами: Юникод, Символы, представленные в Юникоде и Юникод в операционных системах Microsoft.

Во-вторых: Юникод — только на то юникод, чтобы описать все символы всех языков в мире в цифровом виде. При этом если текущий код символа есть китайский иероглиф, а китайской локали у меня в системе нету, то системе глубоко на*р*ть на то, однозначно или не однозначно код юникодового символа определяет его начертание, если она умеет его нарисовать — нарисует, не умеет — не нарисует, а умение это определяется техничискими характеритиками, т.е. наличием соответствующей локали. Я как пользователь Винды не держу в себе желания иметь все мильйон мильйонов всевозможных локалей доступных на планете Земля, и только если мне стукнет в башку читать иероглифи китаёз или санкрит или письменность аборигенов Северной Америки, я поставлю себе эти локали, а до тех пор нафиг они мне не нужны!

Ну а консоль? А что консоль? Скажем при русской локали по умолчанию консолька отбражает русские буквы в кодировке DOS-866, а уменя эти букавки в Windows CP1251 сидят, когда я код пишу. Виндовая консоль — это вообще отдельная песня. Там много всякого говна для совместимости зарыто. Если я пишу под консоль, то в коде приложений, если я общаюсь с std::wcout и хочу чтобы он показывал мои русские букавки, то говорю ему, мол дружище зафигачь к себе в пузентий такую-то локаль плз. При этом зафигачит он её или не зафигачит будет зависеть от того, есть ли таковая локаль в системе, и если нет, то ему, как это и положено на самом деле, глубоко плевать на однозначность или не однозначность начертания кириллицы, потому что нифу о том ЧТО именно рисовать в консоли он не знает. При этом если не нравится поведение по умолчанию, то реализуйте свою консоль, которая нативно с юникодом будет дружить. При этом не забудьте реализовать у свой консоли функцию WriteConsoleW_W_W_ВЭЭЭЭЭ() специально для кривых компиллеров типа борландовского, которые не могут нормально std::wcout построить.

Насчёт различных реализаций юникода, взгляните например на списочеГ реализаций, которые поддерживает библиотека iconv:

UTF-8
UCS-2, UCS-2BE, UCS-2LE
UCS-4, UCS-4BE, UCS-4LE
UTF-16, UTF-16BE, UTF-16LE
UTF-32, UTF-32BE, UTF-32LE
UTF-7
C99, JAVA
UCS-2-INTERNAL, UCS-4-INTERNAL

P.S.: ... вы что, действительно считаете это нормальным: писать в консоль китайскими иероглифами?

P.P.S.: ... я думаю, что вы понимаете, что писать в консоль API-шной функцией — есть занятие для извращенцев, ведь если вы свою консольную софтину завтра захотите собрать с помощью GNU/С++ Compiler для работы например на Linux, то к удивлению функции WriteConsoleW_W_W_ВЭЭЭЭЭ() там не окажется, а вот std::cout/std::wcout будет работать как и ожидается, и русские символы будет печатать (конечно если локаль стоит :) )
... и ещё: выкиньте нафиг свой Борланд Компиллер, он, как ваш пример прекрасно показал, ни фига с юникодами не дружит ...

Плюс ещё: wcout != UNICODE, wcout — есть просто шаблон класса потока, специализированный не char а wchar_t. Вот и всё. Сомневаюсь, что он об юникоде вообще что-то знает. А когда вы код пишите, то все строковые литералы вы пишите используя некую неюникодовую кодировку, например CP1251. Я вот даже не знаю, что будет представлять из себя s, если напиcать wchar_t* s = L"А тра ля ля", будет ли после компилляции s содержать текст в юникоде или, s будет содержать текст в кодовой странице CP1251, просто вместо char использовать wchar_t. ХЗ, это надо тестить. Вот вы потестите и расскажите нам здесь результаты, было б интересно.
Ну а уж, извините, если wcout у вас и английский алфавит не показывает, то при чём тут вообще Юникод?

P.S.: ещё раз говорю — выкинте нафик свой борланд!

pepsicoca wrote:

> Вот это мне как раз и непонятно. На то и Юникод, чтобы забыть о
> переключении таблиц символов. Если есть Юникодная строка, зачем мне
> указывать локаль для потока? Код Юникодного символа ОДНОЗНАЧНО
> определяет его начертание и принадлежность к тому или иному алфавиту.
> Зачем еще указывать локаль?

Локаль -- это не только кодировка символов.

потом, приложение может быть юникодным,
а локаль окружения, в котором оно запускается -- не юникодным.


Но в данном случае в винде просто одна консоль на всех.
И юникодных, и нет.