что вы обычно используете для текста?
я както автоматом перешел везде на wchar_t, но заметил по постам в разных стековерфловах отвечают используя char практически всегда
потом подумал что в теории можно и char обойтись в режиме мультибайта, но будут проблемы с производитедльностью, если нужны какието манипуляции со строками
может быть оптимальнее юзать char для разных идентификаторов т.е. там где может быть только латиница, а для контетнта — мультибайт?
но еще так не пробовал , и пока не знаю , может быть много расходов на конвертацию туда сюда
а у вас как?
и насколько вообще достаточно wchar_t для локализаций? есть ли там всё на все случаи?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, σ, Вы писали:
B>>и насколько вообще достаточно wchar_t для локализаций? есть ли там всё на все случаи?
σ>wchar_t нинужен, от слова совсем.
А в винде с АПИ как будешь работать?
_____________________
С уважением,
Stanislav V. Zudin
B>>>и насколько вообще достаточно wchar_t для локализаций? есть ли там всё на все случаи?
σ>>wchar_t нинужен, от слова совсем.
SVZ>А в винде с АПИ как будешь работать?
Здравствуйте, σ, Вы писали:
SVZ>>А в винде с АПИ как будешь работать?
σ>Во-первых, в WinAPI WCHAR, а не wchar_t, так что аргумент мимо.
winnt.h
#ifndef _MAC
typedef wchar_t WCHAR; // wc, 16-bit UNICODE character#else// some Macintosh compilers don't define wchar_t in a convenient location, or define it as a chartypedef unsigned short WCHAR; // wc, 16-bit UNICODE character#endif
Здравствуйте, Barbar1an, Вы писали:
B>что вы обычно используете для текста? B>я както автоматом перешел везде на wchar_t, но заметил по постам в разных стековерфловах отвечают используя char практически всегда
У нас операций со строками мало. 99% это зачитать из файла и вывести в неизмененном виде, найти строку в хеше, да и всё, пожалуй.
utf8 нас полностью устраивает.
Контейнеры — свои, для обмена строками используем обёртку над std::string.
При работе с WinAPI конвертим в "широкую" строку.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Barbar1an, Вы писали: B>а у вас как?
Где локализированная строка воспринимается как целое (словарь локализаций строк, например), там char в UTF-8, там где идёт работа с текстом как с набором букв (эдит бокс, например), там wchar_t. Ну и привязки к API, там уже как API потребует.
σ>>Во-первых, в WinAPI WCHAR, а не wchar_t, так что аргумент мимо.
SVZ>winnt.h
SVZ>
#ifndef _MAC
typedef wchar_t WCHAR; // wc, 16-bit UNICODE character#else// some Macintosh compilers don't define wchar_t in a convenient location, or define it as a chartypedef unsigned short WCHAR; // wc, 16-bit UNICODE character#endif
Ого, ну ничего себе, ты смог найти на что WCHAR тайпдефнут!
Получается, надо использовать wchar_t, ведь существование тайпдефа говорит о том, что надо писать в коде тип, на который делается алиас (wchar_t), а не сам алиас (WCHAR), правильно?
σ>>А в-нулевых, https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
SVZ>Вот только "As of Windows Version 1903".
Да, для чего-нибудь типа Windows 95 не подходит, беда...
Здравствуйте, Barbar1an, Вы писали:
B>что вы обычно используете для текста?
std::string
B>я както автоматом перешел везде на wchar_t, но заметил по постам в разных стековерфловах отвечают используя char практически всегда
Правильно делают.
B>потом подумал что в теории можно и char обойтись в режиме мультибайта, но будут проблемы с производитедльностью, если нужны какието манипуляции со строками
У нас все манипуляции со строками, включая парсеры и строковый-формат не отличаются от работы с ANSI строками, т.к. детектировать в 99% нужно только подмножество ASCII < 0x80. Если ты нашел в utf-8 строке 'a'- то это именно она, если ',' — то это запятая. Единственно что нужно помнить, всегда соблюдать порядок код юнитов (просто работай со строкой как с контейнером байт) и проблем не будет. Честно, мне вообще не понятно в чем проблема работать с UTF-8. Если символ меньше 0x80, то работаешь с ним как с ASCII, если больше, то пропускаешь сохраняя порядок.
B>может быть оптимальнее юзать char для разных идентификаторов т.е. там где может быть только латиница, а для контетнта — мультибайт?
Сейчас активно портирую код под Linux — проблем нет. std::string замечательно передаются и русские символы и китайские и даже вперемешку.
B>но еще так не пробовал , и пока не знаю , может быть много расходов на конвертацию туда сюда
Конвертация происходит только вокруг вызова API заточенного на Unicode кодировку отличную от UTF-8. В Linux и так всё UTF-8, в Windows собирается с флагом UNICODE и конвертируется туда-сюда. По сравнению с накладными расходами на сами вызовы, разница не заметна.
B>а у вас как? B>и насколько вообще достаточно wchar_t для локализаций? есть ли там всё на все случаи?
wchar_t не нужен, т.к. не понятно какая кодировка в такой строке лежит UTF-16 или UTF-32. Для работы с текстом посимвольно всё равно не подходит ни та ни та. Кодировка — это кодировка, она для хранения и потоковой передачи.
P.S. На правах рекламы. В процессе переезда под Linux у меня отпочковываются маленькие полезные библиотеки. Если что, вот: Simple UTF library for C++, может пригодится.
Здравствуйте, Barbar1an, Вы писали:
B>а у вас как?
У нас на винде был wchar_t т.к. "типо юникод" везде. Хотя это и фикция. B>и насколько вообще достаточно wchar_t для локализаций? есть ли там всё на все случаи?
Я пришёл в выводу, что рассматривая строку как некий контейнер байтов для чего-то с какой-то кодировкой удобнее использовать char, однако для работы со строками как строками надо использовать специальный класс который бы учитывал нюансы UTF-8 и давал возможности поиска, замены и т.п. С другой стороны, есть АПИ винды где всё использует wchar_t "типа для UTF-8 совместимости" (ну я надеюсь что так задумывалось).
Здравствуйте, Kernan, Вы писали:
>С другой стороны, есть АПИ винды где всё использует wchar_t "типа для UTF-8 совместимости" (ну я надеюсь что так задумывалось).
Во-первых, АПИ Windows есть в 2 вариантах — ANSI и UNICODE. Правда, первые функции обычно вызывают вторые.
Здравствуйте, Barbar1an, Вы писали:
B>что вы обычно используете для текста?
Зависит от обстоятельств. Как правило, мы используем тип char для представления строк в UTF-8, в основном в
тех точках, где идет взаимодействие с внешним миром, потому что UTF-8 обладает некоторыми достоинствами, а еще
он очень популярен. Ну а "внутри" этот char/UTF-8 может конвертироваться во что-то другое. Например, в Windows
это wchar_t/UTF-16 — для данной ОС это наиболее естественный способ. А иногда еще лучше использовать UTF-32,
т.к. писать парсеры и некоторые алгоритмы, работающие с символами фиксированной длины, намного приятнее
(такой подход используется в библиотеке ICU, если не изменяет память).
B>я както автоматом перешел везде на wchar_t, но заметил по постам в разных стековерфловах отвечают используя char практически всегда
Ну, в целом-то разумно. Но зависит от того, в какой системе ты работаешь и с какими компонентами.
Советы типа "never use wchar_t" могут показаться смешными, если посмотреть на них под ракурсом
разработки под Windows, где 99% системных API так или иначе используют wchar_t, а некоторые функции
вообще работают ТОЛЬКО с wchar_t (см., например, CompareStringEx или FindNLSStringEx).
B>и насколько вообще достаточно wchar_t для локализаций?
Не уверен, что понял вопрос ))
Но знаю точно, что тема обработки текста и Unicode на самом деле гораздо более глубокая и сложная, чем
может показаться на первый взгляд, и для некоторых задач выбор между char/wchar_t или между UTF-8 и
UTF-16/32 вряд ли будет вообще иметь какое-то значение...
Здравствуйте, Barbar1an, Вы писали:
B>а у вас как?
тоже много спрашивал людей на эту тему
в результате, (в windows) я делаю так:
#ifdef UNICODE
using tstring = std::wstring;
// тут ещё немного разного, потоки, boost#else
using tstring = std::string;
// тут ещё немного разного, потоки, boost#endif
(t — от tchar.h)
переход 8 <-> 16 происходит только в настройках проекта
Здравствуйте, Chorkov, Вы писали:
vsb>>Имхо, uint8_t надо использовать в кодировке UTF-8. wchar_t вообще максимально бесполезный тип.
C>char8_t (начиная с c++20).
Здравствуйте, Pavel Dvorkin, Вы писали:
>>С другой стороны, есть АПИ винды где всё использует wchar_t "типа для UTF-8 совместимости" (ну я надеюсь что так задумывалось). PD>Во-первых, АПИ Windows есть в 2 вариантах — ANSI и UNICODE. Правда, первые функции обычно вызывают вторые.
Но есть нюанс. Так называемый ANSI вариант совсем не ANSI, а вполне может быть мультибайтовой кодировкой, где один символ представлен последовательностью байтов, а интерпретация строки зависит это от текущей кодовой страницы.
PD>Что же касается UTF8 совместимости, то PD>Формат UTF-8 был разработан 2 сентября 1992 PD>а разработка Windows NT 3.1 началась в ноябре 1988 , так что о совместимости с UTF8 и речи быть не могло.
Сам я не тестировал, но согласно документации, несмотря на то, что UTF8 был придуман позже, чем разработан виндовый API, возможность нативно использовать UTF-8 в последних версиях Windows есть благодаря продуманной системе кодировок. Если кодовую страницу установить в UTF-8, то со всеми строками можно будет работать в этом формате с использованием "ANSI" вариантов API.
