Здравствуйте, fk0, Вы писали:
fk0> Если он не интегрирован в libc штатно -- оно не более чем жалкая поделка финских студентов.
В glibc, по идее, есть. А вообще трололо.

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

GN>>Используя C, что входит в стандартную библиотеку C++:
GN>>

GN>>int main()
GN>>{
GN>>  using namespace std;
GN>>  wstring ws = L"wide string";
GN>>  //setlocale(LC_ALL, "russian");
GN>>  ostream_iterator<char> osi(cout);
GN>>  transform(ws.begin(), ws.end(), osi, wctob);
GN>>}
GN>>

fk0> Говнокод.

Дык, сломай его.

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, скажу что у меня руки не оттуда растут

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

GN>>Ровно как и wctob не будет конвертировать в более чем однобайтное представление.
MC>Ну я на это и намекал.

Ээ... это только я понял, что под "преобразованием в char" подразумевается не "в последовательность char"?

MC>Кстати, мне почему-то кажется, что с iconv будет проще, чем со всякими ортодоксатьными сиплюсплюсными потоками-шаблонами.

Может быть даже не проще, а лучше, но это не Стандарт. utf-8 появится только в новом Стандарте, отсюда, наверное и отсутствие его в "в бусте (в частности, xpressive)".

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

fk0> Свобода -- это рабство. (C)

"хлеба и зрелищь"?

fk0> Маны какбе подсказывают и уберегают от говнокода.

Не заметно. Посмотри внимательно: в твоем коде

Автор: fk0
Дата: 11.02.10

потенциальное переполнение буфера.

fk0> Жителям свободной страны конечно наплевать на internationalized characters, но неизвестно кто будет пользоваться их (говно)софтом.

Открою секрет: не-православная-ОС нативно поддерживает эти самые "internationalized characters", поэтому мне и в голову не придёт хранить что то такое в char[] и заниматься конверсиями из пустого в порожнее, без особых на то причин.

fk0>И даже в линухе это может не работать в некоторых случаях (например, при несгенерированной локали, как я понимаю, фиг что будет).

То есть отвергнув одно, ты осознанно предложил полурешение

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

fk0>>$ LC_ALL=ru_RU.UTF-8 ./a.out | iconv -f utf8
fk0>>wcstombs: Перевед мир.
fk0>>wctomb: .
fk0>>[/c]
fk0>> В последней строке сущность говнокода проявлена.
GN>То есть подменил строку для конверсии, установил вместо однобайтной локали мультибайтную и таким образом доказал? что многобайтный символ нельзя привести в 1 char

Я дурацких ухмылок не понимаю.

Да, нельзя. Албанский работать перестанет.

GN>

GN>int main()
GN>{
GN>  setlocale(LC_ALL, "");
GN>  wprintf(L"Перевед мир.");
GN>  printf("Перевед мир.");
GN>}
GN>

GN>MSVC такое нормально переварит кстати,

Нормально -- это ортогонально к результату выдаваемому 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-битной кодировке, в исходнике.

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

fk0>> Маны какбе подсказывают и уберегают от говнокода.
GN>Не заметно. Посмотри внимательно: в твоем коде

Автор: fk0
Дата: 11.02.10

потенциальное переполнение буфера.

Мой код писался какбе для демонстрации (не)работы wcstomb, а не как академический пример правильного программирования.

fk0>> Жителям свободной страны конечно наплевать на internationalized characters, но неизвестно кто будет пользоваться их (говно)софтом.
GN>Открою секрет: не-православная-ОС нативно поддерживает эти самые "internationalized characters", поэтому мне и в голову не придёт хранить что то такое в char[] и заниматься конверсиями из пустого в порожнее, без особых на то причин.

В итоге они вообще не используют библиотеку C и задают здесь вопрос как сконвертить. Ага. И все функции там _A и _W на всякий случай. При чём из файла они всё равно читают _A и вынуждены как-то сконвертить. Этот секрет хорошо звучит только в маркетинге, до тех пор пока никто не знает как же оно там внутри устроено.

fk0>>И даже в линухе это может не работать в некоторых случаях (например, при несгенерированной локали, как я понимаю, фиг что будет).
GN>То есть отвергнув одно, ты осознанно предложил полурешение

Ты вообще не решение предложил. В смысле не работающее для русского языка.

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

fk0>> Маны какбе подсказывают и уберегают от говнокода.
GN>Не заметно. Посмотри внимательно: в твоем коде

Автор: fk0
Дата: 11.02.10

потенциальное переполнение буфера.

Кстати ложь и провокация. Там есть не потенциальное, а практическое отсутствие терминирующего нуля (printf(buf)).

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

MC>Здравствуйте, fk0, Вы писали:
fk0>> Если он не интегрирован в libc штатно -- оно не более чем жалкая поделка финских студентов.
MC>В glibc, по идее, есть. А вообще трололо.

Если на G* начинается -- однозначно поделка. Православно только ISO/IEC.

Здравствуйте, fk0, Вы писали:
fk0> Если на G* начинается -- однозначно поделка. Православно только ISO/IEC.
Ну тогда -- однозначно трололо.

Здравствуйте, fk0, Вы писали:
fk0>у GCC представление о кодировке "строки" и L"строки" в корне принципиально разное. Первая никак не перекодируется при чтении файла (почему бы не взять кодировку из локали?)
Ага, и при компиляции на машинах с разными локалями будет получаться разный код.

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

MC>Здравствуйте, fk0, Вы писали:
fk0>>у GCC представление о кодировке "строки" и L"строки" в корне принципиально разное. Первая никак не перекодируется при чтении файла (почему бы не взять кодировку из локали?)
MC>Ага, и при компиляции на машинах с разными локалями будет получаться разный код.

Вот я и говорю, этот ваш GCC -- жалкая поделка финских студентов...

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

А>Подскажите, гуру, что на данный момент является стандартом С++ преобразования из wchar_t в char?
А>Нарыл вагон примеров. Все работает, но мне надо для тестового задания точно знать, как ПРАВИЛЬНО и переносимо сделать преобразование.
А>Например, вывести в поток ofstream строку wchar_t (не двоичным образом, а предврительным преобразованием в char).
А>Заранее спасибо.

Уже не помню где, я находил следующий вариант преобразования:

struct widen : std::unary_function<char, wchar_t>
{
   widen(const std::ctype<wchar_t> &ct)
      : charType(ct)
   {}
   wchar_t operator()(char c)
   {
      return charType.widen(c);
   }
private:
   const std::ctype<wchar_t> &charType;
};

struct narrow : std::unary_function<wchar_t, char>
{
   narrow(const std::ctype<wchar_t> &ct)
      : charType(ct)
   {}
   char operator()(wchar_t c)
   {
      return charType.narrow(c);
   }
private:
   const std::ctype<wchar_t> &charType;
};
inline std::wstring to_wstring(const std::string &s, const std::locale &curLocale = std::locale::classic())
{
   std::wstring retVal;
   widen w(std::use_facet<std::ctype<wchar_t> >(curLocale));
   std::transform(s.begin(), s.end(), std::back_inserter(retVal), w);
   return retVal;
}

inline std::string to_string(const std::wstring &s, const std::locale &curLocale = std::locale::classic())
{
   std::string retVal;
   narrow n(std::use_facet<std::ctype<wchar_t> >(curLocale));
   std::transform(s.begin(), s.end(), std::back_inserter(retVal), n);
   return retVal;
}

Это может быть и переносимый вариант, но железно тормозной. По сравнению с использованием макросов ATL, этот вариант медленнее на порядок.

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

fk0> Вот я и говорю, этот ваш GCC -- жалкая поделка финских студентов...

Уже третий заход, а еды все нет.

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

fk0> Я дурацких ухмылок не понимаю.

fk0> Да, нельзя. Албанский работать перестанет.

Вот для этого случая я не стал искать подходящие условия, как это сделал ты.

    if (i<0) {
        printf("wcstombs: can't convert in current locale.\n");

Обрати внимание на эту подветку

Автор: alsemm
Дата: 10.02.10

где люди более толково донесли твою мысль

fk0> Пока писал абзац выше -- проверил. Таки выводит и в соответствии с локалью всё конвертирует.

Так и должно быть по стандарту происходит конверсия при выводе в стрим. Неужели в манах про это нет?

fk0>glibc 2.7. Пару лет назад где-то, на debian sarge или etch были проблемы и wprintf в файл фактически не работал. Возможно это как-то связано с fwide(), не скажу. Повторюсь, работает всё только в модных новых линухах, у остальных разброд и шатания.

В них C runtime реализован не полно.

fk0> И кстати применение wprintf ломает работу байт-ориентированных фуннкций вроде printf (просто не выводится). Не всё тут так хорошо...

Потому что стримы имеют оринтацию, т.н. byte-oriented и wide-oriented, устанавливается в зависимости от типа первой функции делающей ввод-вывод.

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

GN>>Посмотри внимательно: в твоем коде

Автор: fk0
Дата: 11.02.10

потенциальное переполнение буфера.

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.

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

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

А>>Подскажите, гуру, что на данный момент является стандартом С++ преобразования из wchar_t в char?
А>>Нарыл вагон примеров. Все работает, но мне надо для тестового задания точно знать, как ПРАВИЛЬНО и переносимо сделать преобразование.
А>>Например, вывести в поток ofstream строку wchar_t (не двоичным образом, а предврительным преобразованием в char).
А>>Заранее спасибо.

ST>Уже не помню где, я находил следующий вариант преобразования:

http://rsdn.ru/forum/cpp.applied/3090740.1.aspx

Автор: skeptik_
Дата: 05.09.08

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

ST>Уже не помню где, я находил следующий вариант преобразования:
Имхо лучше такой способ не использовать, по крайней мере в направлении wchar_t -> char из-за проблемы с мультибайтностью

fk0 wrote:

> Вообще я имел ввиду wcstombs. Линух при том, что только в егойной гнутой
> libc более-менее это всё работает. Мне и самому интересно знать где и
> как не работает.

Ну вроде под виндой в VC работает нормально.

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

GN>>>Посмотри внимательно: в твоем коде

Автор: fk0
Дата: 11.02.10

потенциальное переполнение буфера.
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.

То-есть никакого переполнения нет.

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

GN>Вот для этого случая я не стал искать подходящие условия, как это сделал ты.
GN>

GN>    if (i<0) {
GN>        printf("wcstombs: can't convert in current locale.\n");
GN>

GN>Обрати внимание на эту подветку

Автор: alsemm
Дата: 10.02.10

где люди более толково донесли твою мысль

Ниасилел. В текущей локали.

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 чо-та не памагаит. Я б поастерёгса использовать такие функции.