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

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

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

а у вас как?

и насколько вообще достаточно wchar_t для локализаций? есть ли там всё на все случаи?

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

B>что вы обычно используете для текста?

https://stackoverflow.com/questions/45677774/char-vs-wchar-t-when-to-use-which-data-type?noredirect=1&lq=1

B>в теории можно и char обойтись в режиме мультибайта, но будут проблемы с производитедльностью, если нужны какието манипуляции со строками

Например?

B>и насколько вообще достаточно wchar_t для локализаций? есть ли там всё на все случаи?

wchar_t нинужен, от слова совсем.

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

B>>и насколько вообще достаточно wchar_t для локализаций? есть ли там всё на все случаи?

σ>wchar_t нинужен, от слова совсем.

А в винде с АПИ как будешь работать?

B>>>и насколько вообще достаточно wchar_t для локализаций? есть ли там всё на все случаи?

σ>>wchar_t нинужен, от слова совсем.

SVZ>А в винде с АПИ как будешь работать?

Во-первых, в WinAPI WCHAR, а не wchar_t, так что аргумент мимо.
А в-нулевых, https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

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

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 char
typedef unsigned short WCHAR;    // wc,   16-bit UNICODE character
#endif

σ>А в-нулевых, https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

Вот только "As of Windows Version 1903".

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

B>что вы обычно используете для текста?
B>я както автоматом перешел везде на wchar_t, но заметил по постам в разных стековерфловах отвечают используя char практически всегда

У нас операций со строками мало. 99% это зачитать из файла и вывести в неизмененном виде, найти строку в хеше, да и всё, пожалуй.
utf8 нас полностью устраивает.
Контейнеры — свои, для обмена строками используем обёртку над std::string.

При работе с WinAPI конвертим в "широкую" строку.

Здравствуйте, 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 char
typedef 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. Правда, первые функции обычно вызывают вторые.

Например

https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa

Что же касается UTF8 совместимости, то

Формат UTF-8 был разработан 2 сентября 1992

https://ru.wikipedia.org/wiki/UTF-8

а разработка Windows NT 3.1 началась в ноябре 1988 , так что о совместимости с UTF8 и речи быть не могло.

https://ru.wikipedia.org/wiki/Windows_NT_3.1

Здравствуйте, 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 происходит только в настройках проекта

Имхо, uint8_t надо использовать в кодировке UTF-8. wchar_t вообще максимально бесполезный тип.

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

vsb>Имхо, uint8_t надо использовать в кодировке UTF-8. wchar_t вообще максимально бесполезный тип.

char8_t (начиная с c++20).

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

vsb>>Имхо, uint8_t надо использовать в кодировке UTF-8. wchar_t вообще максимально бесполезный тип.

C>char8_t (начиная с c++20).

Чем он отличается от uint8_t?

C>>char8_t (начиная с c++20).

vsb>Чем он отличается от uint8_t?

Более лучше.

Здравствуйте, 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.

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

C>>char8_t (начиная с c++20).

vsb>Чем он отличается от uint8_t?

1) uint8_t — может совпадать с char, а char8_t — всегда отдельный тип.

2) Он именно для этого специально предназначен.
Т.е. читателю кода понятно что функция принимает utf8, без дополнительных комментариев.

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

PD>Что же касается UTF8 совместимости, то
PD>Формат UTF-8 был разработан 2 сентября 1992
PD>а разработка Windows NT 3.1 началась в ноябре 1988 , так что о совместимости с UTF8 и речи быть не могло.

Так, к слову. Меня в своё время прикололо вот это объяснение дяди Раймондо, почему в VC нестандартный %s/%S:

https://devblogs.microsoft.com/oldnewthing/20190830-00/?p=102823

Оказывается, потому, что винда появилась раньше, чем все эти ваши стандарты и юникоды.