std :: wstring VS std :: строка

string? wstring?

std::string - это basic_string, созданный по шаблону на char, а std::wstring на _ 7_.

char vs. wchar_t

char должен содержать символ, обычно 8-битный.
wchar_t должен содержать широкий символ, и тогда все становится сложно:
В Linux wchar_t составляет 4 байта, а в Windows это 2 байта.

А как насчет Unicode?

Проблема в том, что ни char, ни wchar_t напрямую не привязаны к юникоду.

В Linux?

Возьмем ОС Linux: моя система Ubuntu уже поддерживает Unicode. Когда я работаю со строкой символов, она изначально закодирована в UTF-8 (т.е. Unicode строка символов). Следующий код:

#include <cstring>
#include <iostream>

int main(int argc, char* argv[])
{
   const char text[] = "olé" ;


   std::cout << "sizeof(char)    : " << sizeof(char) << std::endl ;
   std::cout << "text            : " << text << std::endl ;
   std::cout << "sizeof(text)    : " << sizeof(text) << std::endl ;
   std::cout << "strlen(text)    : " << strlen(text) << std::endl ;

   std::cout << "text(ordinals)  :" ;

   for(size_t i = 0, iMax = strlen(text); i < iMax; ++i)
   {
      std::cout << " " << static_cast<unsigned int>(
                              static_cast<unsigned char>(text[i])
                          );
   }

   std::cout << std::endl << std::endl ;

   // - - - 

   const wchar_t wtext[] = L"olé" ;

   std::cout << "sizeof(wchar_t) : " << sizeof(wchar_t) << std::endl ;
   //std::cout << "wtext           : " << wtext << std::endl ; <- error
   std::cout << "wtext           : UNABLE TO CONVERT NATIVELY." << std::endl ;
   std::wcout << L"wtext           : " << wtext << std::endl;

   std::cout << "sizeof(wtext)   : " << sizeof(wtext) << std::endl ;
   std::cout << "wcslen(wtext)   : " << wcslen(wtext) << std::endl ;

   std::cout << "wtext(ordinals) :" ;

   for(size_t i = 0, iMax = wcslen(wtext); i < iMax; ++i)
   {
      std::cout << " " << static_cast<unsigned int>(
                              static_cast<unsigned short>(wtext[i])
                              );
   }

   std::cout << std::endl << std::endl ;

   return 0;
}

выводит следующий текст:

sizeof(char)    : 1
text            : olé
sizeof(text)    : 5
strlen(text)    : 4
text(ordinals)  : 111 108 195 169

sizeof(wchar_t) : 4
wtext           : UNABLE TO CONVERT NATIVELY.
wtext           : ol�
sizeof(wtext)   : 16
wcslen(wtext)   : 3
wtext(ordinals) : 111 108 233

Вы увидите, что текст «olé» в char на самом деле состоит из четырех символов: 110, 108, 195 и 169 (не считая завершающего нуля). (Я позволю вам изучить код wchar_t в качестве упражнения)

Итак, работая с char в Linux, вы обычно должны использовать Unicode, даже не подозревая об этом. И поскольку std::string работает с char, std::string уже поддерживает Unicode.

Обратите внимание, что std::string, как и API строки C, будет считать, что строка "olé" состоит из 4 символов, а не из трех. Поэтому вы должны быть осторожны при усечении / игре с символами Unicode, потому что некоторые комбинации символов запрещены в UTF-8.

В Windows?

В Windows это немного иначе. Win32 должен был поддерживать множество приложений, работающих с char и разными кодировками / кодовые страницы, созданные во всем мире до появления Unicode.

Таким образом, их решение было интересным: если приложение работает с char, то строки символов кодируются / печатаются / отображаются на этикетках графического интерфейса пользователя с использованием локальной кодировки / кодовой страницы на машине. Например, «olé» будет «olé» во французской локализованной Windows, но будет чем-то другим в локализованной на кириллицу Windows («olй», если вы используете Windows-1251). Таким образом, «исторические приложения» обычно будут работать по-прежнему.

Для приложений на основе Unicode Windows использует wchar_t, который имеет ширину 2 байта и закодирован в UTF-16, который представляет собой кодировку Unicode на 2-байтовых символах (или, по крайней мере, наиболее совместимый UCS-2, что почти то же самое, что и IIRC).

Приложения, использующие char, называются «многобайтовыми» (потому что каждый глиф состоит из одного или нескольких char), а приложения, использующие wchar_t, называются «widechar» (потому что каждый глиф состоит из одного или двух wchar_t. См. MultiByteToWideChar и WideCharToMultiByte API преобразования Win32 для получения дополнительной информации.

Таким образом, если вы работаете в Windows, вы очень хотите использовать wchar_t (если только вы не используете фреймворк, скрывающий это, например GTK + или QT ... ). Дело в том, что за кулисами Windows работает со строками wchar_t, поэтому даже в исторических приложениях их char строки будут преобразованы в wchar_t при использовании API, такого как SetWindowText() (функция API низкого уровня для установки метки в графическом интерфейсе Win32).

Проблемы с памятью?

UTF-32 составляет 4 байта на символ, поэтому особо нечего добавить, если только текст UTF-8 и текст UTF-16 всегда будут использовать меньше или такой же объем памяти, чем текст UTF-32 (и обычно меньше ).

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

Тем не менее, для других языков (китайский, японский и т. Д.) Используемая память будет либо такой же, либо немного больше для UTF-8, чем для UTF-16.

В целом, UTF-16 будет в основном использовать 2, а иногда и 4 байта на символ (если вы не имеете дело с какими-то эзотерическими языковыми глифами (клингонский? Эльфийский?), Тогда как UTF-8 будет тратить от 1 до 4 байтов.

См. http://en.wikipedia.org/wiki/UTF-8#Compared_to_UTF-16 для получения дополнительной информации.

Заключение

1. Когда следует использовать std :: wstring вместо std :: string?

   В Linux? Почти никогда (§).
   В Windows? Почти всегда (§).
   О кроссплатформенном коде? Зависит от вашего набора инструментов ...

   (§): если вы не используете инструментарий / фреймворк, говорящий иначе

2. Может ли std::string содержать весь набор символов ASCII, включая специальные символы?

   Примечание: std::string подходит для хранения «двоичного» буфера, а std::wstring - нет!

   В Linux? Да.
   В Windows? Только специальные символы доступны для текущего языкового стандарта пользователя Windows.

   Изменить (после комментария от Иоганна Герелла):
   std::string будет достаточно для обработки всех строк на основе char (каждая char является числом от 0 до 255). Но:

   1. ASCII is supposed to go from 0 to 127. Higher chars are NOT ASCII.
   2. char от 0 до 127 будет удерживаться правильно
   3. char от 128 до 255 будет иметь значение в зависимости от вашей кодировки (unicode, non-unicode и т. д.), но он сможет содержать все глифы Unicode, если они закодированы в UTF-8.

3. Поддерживается ли std::wstring почти всеми популярными компиляторами C ++?

   В основном, за исключением компиляторов на основе GCC, которые портированы в Windows.
   Он работает на моем g ++ 4.3.2 (под Linux), и я использовал Unicode API в Win32, начиная с Visual C ++ 6.

4. Что такое широкий символ?

   В C / C ++ это символьный тип, записанный wchar_t, который больше, чем простой char символьный тип. Предполагается, что он будет использоваться для вставки внутри символов, чьи индексы (например, глифы Unicode) больше 255 (или 127, в зависимости от ...).

Я рекомендую избегать std::wstring в Windows или где-либо еще, кроме случаев, когда этого требует интерфейс, или где-либо рядом с вызовами Windows API и соответствующими преобразованиями кодировки в качестве синтаксического сахара.

Мое мнение изложено в http://utf8everywhere.org, соавтором которого я являюсь.

Если ваше приложение не ориентировано на вызовы API, например в основном приложение пользовательского интерфейса, предлагается хранить строки Unicode в std :: string и закодированные в UTF-8, выполняя преобразование рядом с вызовами API. Преимущества, описанные в статье, перевешивают очевидное раздражение преобразования, особенно в сложных приложениях. Это вдвойне верно для многоплатформенной и библиотечной разработки.

А теперь, отвечая на ваши вопросы:

1. Несколько слабых причин. Он существует по историческим причинам, когда расширение символов считалось правильным способом поддержки Unicode. Теперь он используется для интерфейса API, которые предпочитают строки UTF-16. Я использую их только в непосредственной близости от таких вызовов API.
2. Это не имеет ничего общего с std :: string. Он может содержать любую кодировку, которую вы в него вставляете. Вопрос только в том, как Вы относитесь к его содержанию. Я рекомендую UTF-8, поэтому он сможет правильно хранить все символы Unicode. Это обычная практика в Linux, но я думаю, что программы Windows тоже должны это делать.
3. No.
4. Широкий символ - это сбивающее с толку имя. На заре Unicode считалось, что символ можно закодировать двумя байтами, отсюда и название. Сегодня это означает «любую часть символа длиной два байта». UTF-16 рассматривается как последовательность таких пар байтов (также называемых широкими символами). Символ в UTF-16 принимает одну или две пары.

Итак, каждый читатель здесь должен иметь четкое представление о фактах и ​​ситуации. Если нет, то вы должны прочитать чрезвычайно исчерпывающий ответ Паэрцебала [кстати: спасибо!].

Мой прагматический вывод шокирующе прост: вся эта "кодировка символов" в C ++ (и STL) в значительной степени нарушена и бесполезна. Винить в этом Microsoft или нет, это все равно не поможет.

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

1. примите, что вы должны сами нести ответственность за кодирование и преобразование (и вы увидите, что многое из этого довольно тривиально)

2. используйте std :: string для любых строк в кодировке UTF-8 (только typedef std::string UTF8String)

3. согласитесь, что такой объект UTF8String - просто глупый, но дешевый контейнер. Никогда не обращайтесь и / или не управляйте символами в нем напрямую (без поиска, замены и т. Д.). Вы могли бы, но вы действительно очень, очень не хотите тратить свое время на написание алгоритмов обработки текста для многобайтовых строк! Даже если другие люди уже совершали такие глупые поступки, не делайте этого! Будь как будет! (Ну, есть сценарии, в которых это имеет смысл ... просто используйте для них библиотеку ICU).

4. используйте std :: wstring для строк в кодировке UCS-2 (typedef std::wstring UCS2String) - это компромисс и уступка беспорядку, который привнес в WIN32 API). Для большинства из нас достаточно UCS-2 (подробнее об этом позже ...).

5. используйте экземпляры UCS2String всякий раз, когда требуется посимвольный доступ (чтение, управление и т. д.). Любая символьная обработка должна выполняться в НЕ-многобайтовом представлении. Это просто, быстро, легко.

6. добавьте две служебные функции для преобразования между UTF-8 и UCS-2:

   UCS2String ConvertToUCS2( const UTF8String &str );
   UTF8String ConvertToUTF8( const UCS2String &str );
   

Преобразования просты, здесь должен помочь Google ...

Вот и все. Используйте UTF8String везде, где важна память, и для всех операций ввода-вывода UTF-8. Используйте UCS2String везде, где строка должна анализироваться и / или обрабатываться. Вы можете конвертировать между этими двумя представлениями в любое время.

Альтернативы и улучшения

• преобразования из & в однобайтовые кодировки символов (например, ISO-8859-1) могут быть реализованы с помощью простых таблиц перевода, например const wchar_t tt_iso88951[256] = {0,1,2,...}; и соответствующий код для преобразования в UCS2 и из него.

• если UCS-2 недостаточно, переключитесь на UCS-4 (typedef std::basic_string<uint32_t> UCS2String)

ICU или другие библиотеки Unicode?

Для продвинутых пользователей.

1. Если вы хотите, чтобы в вашей строке хранились широкие символы. wide зависит от реализации. Visual C ++ по умолчанию 16 бит, если я правильно помню, а GCC по умолчанию в зависимости от цели. Здесь длина 32 бита. Обратите внимание: wchar_t (тип широких символов) не имеет ничего общего с юникодом. Просто гарантируется, что он может хранить все члены самого большого набора символов, поддерживаемого реализацией его локали, и по крайней мере столько же, сколько char. Вы можете хранить строки Юникода в std::string, используя также кодировку utf-8. Но он не поймет значения кодовых точек Unicode. Таким образом, str.size() не даст вам количество логических символов в вашей строке, а просто количество элементов char или wchar_t, хранящихся в этой строке / wstring. По этой причине разработчики оболочки gtk / glib C ++ разработали Glib::ustring, который может обрабатывать UTF-8.

   Если ваш wchar_t имеет длину 32 бита, вы можете использовать utf-32 в качестве кодировки Unicode, и вы можете хранить и строки Unicode, используя фиксированную (utf-32 - фиксированная длина ) кодирование. Это означает, что функция s.size() вашей wstring затем вернет нужное количество элементов wchar_t и логических символов.

2. Да, char всегда имеет длину не менее 8 бит, что означает, что он может хранить все значения ASCII.
3. Да, его поддерживают все основные компиляторы.

Я часто использую std :: string для хранения символов utf-8 без каких-либо проблем. Я настоятельно рекомендую сделать это при взаимодействии с API, которые также используют utf-8 в качестве собственного строкового типа.

Например, я использую utf-8 при взаимодействии моего кода с интерпретатором Tcl.

Главное предостережение - это длина std :: string, которая больше не является количеством символов в строке.

Хороший вопрос! Я считаю, что КОДИРОВАНИЕ ДАННЫХ (иногда также используется CHARSET) - это МЕХАНИЗМ ВЫРАЖЕНИЯ ПАМЯТИ, предназначенный для сохранения данных в файл или передачи данных через сети, поэтому я отвечаю на этот вопрос так:

1. Когда мне следует использовать std :: wstring вместо std :: string?

Если платформа программирования или функция API являются однобайтовыми, и мы хотим обработать или проанализировать некоторые данные Unicode, например, прочитанные из файла Windows'.REG или сетевого 2-байтового потока, мы должны легко объявить переменную std :: wstring обработать их. например: wstring ws = L "中国 a" (память на 6 октетов: 0x4E2D 0x56FD 0x0061), мы можем использовать ws [0] для получения символа '中' и ws [1] для получения символа '国' и ws [2] для получить символ "а" и т. д.

2. Может ли std :: string содержать весь набор символов ASCII, включая специальные символы?

да. Но обратите внимание: американский ASCII означает, что каждый октет 0x00 ~ 0xFF обозначает один символ, включая печатный текст, такой как «123abc & * _ &», а вы сказали специальный, в основном печатайте его как '.' избегайте путаницы с редакторами или терминалами. А некоторые другие страны расширяют свою собственную кодировку "ASCII", например Китайский, используйте 2 октета для обозначения одного символа.

3. Поддерживается ли std :: wstring всеми популярными компиляторами C ++?

Может быть, или в основном. Я использовал: VC ++ 6 и GCC 3.3, ДА

4. Что такое «широкий характер»?

широкий символ обычно указывает на использование 2 или 4 октетов для хранения символов всех стран. 2 октета UCS2 является репрезентативной выборкой, и далее, например, Английская 'a', его память составляет 2 октета из 0x0061 (по сравнению с ASCII 'a, его память составляет 1 октет 0x61)

1. Если вы хотите хранить «широкие» (Unicode) символы.
2. Да: 255 из них (без 0).
3. да.
4. Вот вводная статья: http://www.joelonsoftware.com/articles/Unicode.html

Приложения, которые не удовлетворены только 256 различными символами, могут использовать либо широкие символы (более 8 бит), либо кодировку переменной длины (многобайтовую кодировку в терминологии C ++), такую ​​как UTF-8. Для широких символов обычно требуется больше места, чем для кодирования с переменной длиной, но они обрабатываются быстрее. Многоязычные приложения, обрабатывающие большие объемы текста, обычно используют широкие символы при обработке текста, но преобразуют его в UTF-8 при сохранении на диск.

Единственная разница между string и wstring - это тип данных символов, которые они хранят. Строка хранит chars, размер которых гарантированно составляет не менее 8 бит, поэтому вы можете использовать строки для обработки, например. Текст ASCII, ISO-8859-15 или UTF-8. В стандарте ничего не говорится о наборе символов или кодировке.

Практически каждый компилятор использует набор символов, первые 128 символов которого соответствуют ASCII. То же самое и с компиляторами, использующими кодировку UTF-8. При использовании строк в UTF-8 или какой-либо другой кодировке переменной длины важно помнить, что индексы и длины измеряются в байтах, а не в символах.

Тип данных wstring - wchar_t, размер которого не определен в стандарте, за исключением того, что он должен быть по крайней мере таким же большим, как char, обычно 16 или 32 бит. wstring может использоваться для обработки текста в кодировке расширенных символов, определенной в реализации. Поскольку кодировка не определена в стандарте, преобразовать между строками и wstrings непросто. Нельзя также предположить, что wstrings имеют кодировку фиксированной длины.

Если вам не нужна многоязычная поддержка, вы можете использовать только обычные строки. С другой стороны, если вы пишете графическое приложение, часто бывает, что API поддерживает только широкие символы. Тогда вы, вероятно, захотите использовать такие же широкие символы при обработке текста. Имейте в виду, что UTF-16 - это кодировка переменной длины, а это означает, что вы не можете предполагать, что length() вернет количество символов. Если API использует кодировку фиксированной длины, такую ​​как UCS-2, обработка упрощается. Преобразование между широкими символами и UTF-8 сложно сделать переносимым способом, но опять же, ваш API пользовательского интерфейса, вероятно, поддерживает преобразование.

1. когда вы хотите использовать строки Unicode, а не только ascii, полезно для интернационализации
2. да, но он не работает с 0
3. не в курсе того, что не
4. широкий символ - это специфичный для компилятора способ обработки представления фиксированной длины символа Юникода, для MSVC это 2-байтовый символ, для gcc, как я понимаю, это 4 байта. и +1 за http://www.joelonsoftware.com/articles/Unicode.html

Здесь есть несколько очень хороших ответов, но я думаю, что могу добавить пару вещей, касающихся Windows / Visual Studio. Это основано на моем опыте работы с VS2015. В Linux основной ответ - использовать везде в кодировке UTF-8 std::string. В Windows / VS все становится сложнее. Вот почему. Windows ожидает, что строки, хранящиеся с использованием chars, будут закодированы с использованием кодовой страницы языкового стандарта. Это почти всегда набор символов ASCII, за которым следуют 128 других специальных символов в зависимости от вашего местоположения. Позвольте мне просто заявить, что это не только при использовании Windows API, есть еще три основных места, где эти строки взаимодействуют со стандартным C ++. Это строковые литералы, выводимые в std::cout с использованием << и передача имени файла в std::fstream.

Скажу сразу, что я программист, а не языковый специалист. Я понимаю, что USC2 и UTF-16 не одно и то же, но для моих целей они достаточно близки, чтобы быть взаимозаменяемыми, и я использую их как таковые здесь. На самом деле я не уверен, что использует Windows, но, как правило, мне и знать не нужно. В этом ответе я указал UCS2, поэтому заранее извините, если я кого-нибудь расстрою своим незнанием этого вопроса, и я рад изменить его, если у меня что-то не так.

Строковые литералы

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

Если вы введете какие-либо строковые литералы, которые не могут быть представлены вашей кодовой страницей, VS попросит вас сохранить файл как Unicode. Затем файл будет закодирован как UTF-8. Это означает, что все символы, отличные от ASCII (включая те, которые находятся на вашей кодовой странице), будут представлены 2 или более байтами. Это означает, что если вы передадите свой источник кому-то другому, он будет выглядеть так же. Однако перед передачей исходного кода компилятору VS преобразует текст в кодировке UTF-8 в текст, закодированный для кодовой страницы, и любые символы, отсутствующие в кодовой странице, заменяются на ?.

Единственный способ гарантировать правильное представление строкового литерала Unicode в VS - это поставить перед строковым литералом знак L, что сделает его широким строковым литералом. В этом случае VS преобразует текст в кодировке UTF-8 из файла в UCS2. Затем вам нужно передать этот строковый литерал в конструктор std::wstring или преобразовать его в utf-8 и поместить в std::string. Или, если вы хотите, вы можете использовать функции Windows API для его кодирования, используя свою кодовую страницу, чтобы поместить его в std::string, но тогда вы также можете не использовать широкий строковый литерал.

std :: cout

При выводе на консоль с использованием << вы можете использовать только std::string, а не std::wstring, и текст должен быть закодирован с использованием кодовой страницы вашего языкового стандарта. Если у вас есть std::wstring, вы должны преобразовать его с помощью одной из функций Windows API, и любые символы, отсутствующие на вашей кодовой странице, будут заменены на ? (возможно, вы можете изменить символ, я не могу вспомнить).

std :: fstream имена файлов

ОС Windows использует UCS2 / UTF-16 для имен файлов, поэтому независимо от вашей кодовой страницы вы можете иметь файлы с любым символом Unicode. Но это означает, что для доступа или создания файлов с символами, которых нет на вашей кодовой странице, вы должны использовать std::wstring. Другого пути нет. Это специальное расширение Microsoft для std::fstream, поэтому, вероятно, не будет компилироваться в других системах. Если вы используете std :: string, вы можете использовать только те имена файлов, которые содержат только символы на вашей кодовой странице.

Ваши варианты

Если вы просто работаете над Linux, то вы, вероятно, не зашли так далеко. Просто используйте везде UTF-8 std::string.

Если вы просто работаете в Windows, просто везде используйте UCS2 std::wstring. Некоторые пуристы могут сказать, что используйте UTF8, а затем конвертируйте, когда это необходимо, но зачем возиться с этими хлопотами.

Если вы кроссплатформенный, то, честно говоря, это беспорядок. Если вы пытаетесь использовать UTF-8 везде в Windows, вам нужно быть очень осторожным со строковыми литералами и выводом на консоль. Вы можете легко испортить там свои строки. Если вы используете std::wstring везде в Linux, у вас может не быть доступа к широкой версии std::fstream, поэтому вам придется выполнить преобразование, но риск повреждения отсутствует. Так что лично я считаю, что это лучший вариант. Многие не согласятся, но я не одинок - это, например, путь, по которому идут wxWidgets.

Другой вариант - ввести unicodestring как std::string в Linux и std::wstring в Windows и иметь макрос под названием UNI () с префиксом L в Windows и ничего в Linux, затем код

#include <fstream>
#include <string>
#include <iostream>
#include <Windows.h>

#ifdef _WIN32
typedef std::wstring unicodestring;
#define UNI(text) L ## text
std::string formatForConsole(const unicodestring &str)
{
    std::string result;
    //Call WideCharToMultiByte to do the conversion
    return result;
}
#else
typedef std::string unicodestring;
#define UNI(text) text
std::string formatForConsole(const unicodestring &str)
{
    return str;
}
#endif

int main()
{

    unicodestring fileName(UNI("fileName"));
    std::ofstream fout;
    fout.open(fileName);
    std::cout << formatForConsole(fileName) << std::endl;
    return 0;
}

я думаю, будет хорошо на любой платформе.

Ответы

Итак, чтобы ответить на ваши вопросы

1) Если вы программируете для Windows, то все время, если кросс-платформенный, то, возможно, все время, если вы не хотите иметь дело с возможными проблемами повреждения в Windows или писать код для конкретной платформы #ifdefs, чтобы обойти различия, если только используя линукс тогда никогда.

2) Да. Кроме того, в Linux вы также можете использовать его для всех Unicode. В Windows вы можете использовать его только для всего Юникода, если вы выберете ручное кодирование с использованием UTF-8. Но Windows API и стандартные классы C ++ ожидают, что std::string будет закодирован с использованием кодовой страницы локали. Сюда входят все символы ASCII плюс еще 128 символов, которые меняются в зависимости от кодовой страницы, для которой настроен ваш компьютер.

3) Я так считаю, но если нет, то это просто определение типа 'std :: basic_string' с использованием wchar_t вместо char

4) Широкий символ - это тип символа, размер которого больше, чем стандартный тип char, равный 1 байту. В Windows это 2 байта, в Linux - 4 байта.

1) Как упоминал Грег, wstring полезен для интернационализации, именно тогда вы будете выпускать свой продукт на языках, отличных от английского.

4) Обратите внимание на широкий символ http://en.wikipedia.org/wiki/Wide_character

Когда НЕ следует использовать широкие символы?

Когда вы пишете код до 1990 года.

Очевидно, я перевернулся, но на самом деле сейчас 21 век. 127 знаков давно перестали быть достаточными. Да, вы можете использовать UTF8, но зачем беспокоиться о головной боли?