wchar_t и юникод

почему тебя так интересует мнение заведомо безграмотных людей?

Меня больше интересует чтобы они исчезли на свалке истории. Программы с wchar_t обычно не работают. Это точно пошло бы на пользу индустрии.

Меня больше интересует чтобы они исчезли на свалке истории.

им на смену всегда приходят новые.

Отвечу во славу истории:

1. В общем случае нет → What size wchar_t do I need for Unicode?
2. RFC 3629, Unicode

https://stackoverflow.com/questions/12590255/what-does-stdc-iso-10646-exactly...

#include <stdio.h>

int main(void)
{
    printf("%ld\n", __STDC_ISO_10646__);
}

На моей системе

201505

А если открыть стандартную библиотеку, то можно увидеть

/* wchar_t uses Unicode 8.0.0.  Version 8.0 of the Unicode Standard is
   synchronized with ISO/IEC 10646:2014, plus Amendment 1 (published
   2015-05-15).  */
#define __STDC_ISO_10646__		201505L

стандарт юникода поддерживает сишечка в типе wchar_t

Какая связь между юникодом и wchar_t?

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf

193 страница

The following macro names are conditionally defined by the implementation:
__STDC_ISO_10646__
An  integer  constant  of  the  form
yyyymmL
(for  example,
199712L
).  If  this  symbol  is  defined,  then  every  character  in  the  Unicode
required  set,  when  stored  in  an  object  of  type
wchar_t
,  has  the  same
value  as  the  short  identifier  of  that  character.   The
Unicode  required  set
consists of all the characters that are defined by ISO/IEC 10646, along with
all  amendments  and  technical  corrigenda,  as  of  the  specified  year  and
month.  If
some other encoding is used, the macro shall not be defined and
the actual encoding used is implementation-defined.

Криво вставилось, да и ладно...

Так какая кодировка используется?

Implementaion Defined. Но под эти условия подходит только две UTF-32BE и UTF-32LE.

У меня на Linux: UTF-32LE

Хотя безусловно использовать char и UTF8 строки гораздо лучше для портируемости. Но если портируемость не нужна...

А тут написано что на винде он 16 байт.

http://en.cppreference.com/w/cpp/language/types

И?

На Винде этот макрос не определен.

Ещё потоки в c должны быть... Но тоже можно проверить макрос есть ли потоки в с или нет.

Если макрос определен, то wchar_t можно использовать для юникод строк иначе нельзя, всё просто. А по значению макроса можно узнать какую версию юникода поддерживает wchar_t

И именно по-этому C должен умереть.

И именно по-этому C должен умереть.

Что по-этому? От изчезновения C в винде появится полноценная поддержка 32-битного юникода? Включая fat и ntfs? Ну то есть винда заэкономила на спичках, а виноват C?

И именно по-этому C должен умереть.

... сказал человек, который пишет «поэтому» как «по-этому».

В общем-то, всё сходится. Хейтеры.

Конечно не виноват. Правда у других языков таких проблем нет.

Не отрицаю. Сишку я не перевариваю.

Сишку я не перевариваю.

Оно и видно, ваша идиосинкразия вам застилает мозг.

Правда у других языков таких проблем нет.

Вы не юлите, а конкретно приведите пример, какой язык чинит винду, что сразу файлики с йенами начинают создаваться на ntfs.

Другие языки абстрагируются от кодировки ОС.

какой язык чинит винду, что сразу файлики с йенами начинают создаваться на ntfs.

Винда у нас и стандарт JIS X 0213 придумала, оказывается? А файлики с йенами создаются замечательно.

D:\¥>fsutil fsinfo ntfsInfo d:
[...]
NTFS Version   :                   3.1
[...]

Аж отдельная тема для срача!!111

c и c++ тоже абстрагированы от какого-либо внешнего представления символов. Хреново в некоторых местах, но оно есть

Винда у нас и стандарт JIS X 0213 придумала, оказывается?

Вы это к чему?

А файлики с йенами создаются замечательно.

А вот майкрософт говорит, что есть проблема: https://msdn.microsoft.com/ru-ru/library/windows/desktop/dd374047(v=vs.85).aspx

Тут одно из двух:

• msvc не поддерживает символы вне USC-2
• msvc не следует стандарту в этой части

P. S. На самом деле наверняка они свой wchar_t делали во времена «UTF-16 хватит всем»(он тогда ещё не многобайтный был)

char16_t, char32_t (по вкусу) в C++. Вот там - юникод. С вполне понятной репрезентацией, например кодпойнта U+10001.

В отличие от wchar_t.

====

хотя на C и с char16_t и char32_t та же хрень

__STDC_UTF_16_ _ The integer constant 1, intended to indicate that values of type char16_t are UTF−16 encoded. If some other encoding is used, the macro shall not be defined and the actual encoding used is implementation-defined.

На самом деле все делали свой wchar_t как ещё один char, которого уж точно хватит всем, при этом отдавая всё на откуп реализации. В результате

(wchar_t) 5300 не означает ничего, как и L"đð→đśð" не является переносимым, как и L'\x1232'.

(wchar_t) 5300 не означает ничего, как и L"đð→đśð" не является переносимым, как и L'\x1232'

С первым и последним всё ясно. А насчет второго(где строковый литерал) - можно подробнее?

Программы с wchar_t обычно не работают.

Работают. Но, могут быть непереносимы с GNU/Linux'а на винду. Для тех, у кого нет винды, это не проблема.

на винду

На msvc, наверное. Или вы не о специфической реализации wchar_t в компиляторе от MS?

Мне рассказывали так, что в подсистемах винды всё в UTF-16. И wchar_t в винде, соответственно, 16 бит. А в GNU/Linux'е wchar_t - 32 бита. Из этого делался вывод о непортируемости софта с wchar_t (особенно того, который пишет больше 2-х байт в wchar_t) из под GNU/Linux'а в винду.

Думал, mingw использует 32-х битный wchar_t, но беглый гуглинг выдал следующее:

The wide-character parts of the GCC Standard C++ Library (libstdc++) have not yet been fully ported to Windows, so you cannot use most of these features with MinGW

Так с 2009 года

Даже здесь было: https://www.linux.org.ru/forum/development/4164185

Видимо всё из-за того, что сишку придумывали без учёта на интернациализацию, а сделать ос. Тогда в то время это не брали в расчёт ( я про широкие символы ). Учитывая как всё повернулось, и koi8 стали меньше использовать приходится заморачиваться даже с такой простой задачей, как записывать широкие символы. А то и да, одна буква, один байт, классно же, но букв не хватит на все языки. Но говоря о других языках, в которых учитывался широкий символ, тоже было скорее всего на сишке, а раз было написано на сишке, значит с проблемой широких символов они справились. Так что и вы справляйтесь.

1) Нигде не специфицируется как будет прочитан исходник и с какую последовательность байт он будет записан в секцию данных (даже без учёта endianness).

2) Можно рассматривать этот литерал как постедовательность \xXXXX\xYYY\zZZZZZ

Но с #ifdef __STDC_ISO_10646__ проблема 2 не будет проблемой. Только не доводилось видеть чтобы программа не компилировалась когда __STDC_ISO_10646__ не объявлен.

Да, понял. С кодировкой исходника и литералов в бинарнике, думается, подход один: использовать «системную» кодировку и перед компиляцией выполнять что-то вида iconv -f "$orig_source_encoding" < "$source" > "$would_compiled". gcc без явного указания -finput-charset=* её же и использует. Но вообще, согласен - использовать char + libiconv может оказаться проще.

Кстати, с ABI(и сишным, и крестовым) та же проблема. И решение подобное - завязаться на ID поведение

Для исходника и ascii должно хватить

Программы с wchar_t обычно не работают.

это ты с чего взял? дофига нормально написанного софта работает без каких-либо проблем. наверное, лечится выпрямлением рук.

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

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

Ага, и первых версий юникода

Смотря с какой стороны посмотреть: написать переносимо(с некоторыми оговорками) можно, но с 16-ти битным wchar_t теряется абстракция символа, т. е. один wchar_t может и не представлять какой-либо символ и приходится оперировать только строками. Это осложняет задачу

есть мультибайт и есть юникод с кодом страницы. 16 бит в основном всякие китайцы используют. но для интернационализации это иногда нужно.

а вот мультибайт действительно жопа. там нет удобного для программиста деления на символы. и постоянно приходится его переводить в какие-нибудь форматы, с которыми можно работать, и обратно.

для европейских языков хватает UTF-8. и это хорошо и удобно.

а вот мультибайт действительно жопа

Вот и я об этом

ага, сказки про кроссплатформу wchar_t заканчиваются на хотя бы сортировке по алфавиту любого (наперёд заданного) языка.

сделать можно всё, что угодно. при чём тут сказки? ПО, работающее на разных языках, и написанное на С/C++ существует уже десятки лет. люди пишут код, в отличие от соплей, которыми обмазываются неосиляторы. так что не надо мазать их на других.

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

https://ru.wikipedia.org/wiki/Широкий_символ

- разве этой информации не достаточно, или она может быть не соответствует действительности?

что значит «неизвестен»? приложения есть, а кода нет? интересное предположение, но нет. куча редакторов. более того, многие редакторы ещё и умеют в одном документе разные языки совмещать. даже такие, у которых выравнивание в разные стороны и прочее. если руки из правильного места растут - проблем никаких нет. ну а если руки из жопы, то лучше идти двор подметать.

информации предостаточно в стандарте C, чтобы понять, что этим «широким символом» пользоваться нельзя.

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

===

ах да! я забыл, что «широкий символ» никак не связан с юникодом, за исключением макродекларации, которая опциональная.

===

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

информации предостаточно в стандарте C, чтобы понять, что этим «широким символом» пользоваться нельзя.

тем более

- некоторые разработчики почему-то не любят ни стандартов, ни официальной документации