Короткий ответ: НИКАКОЙ .

Как все другие уже записали, много программистов все еще использует TCHARs и соответствующие функции. По моему скромному мнению целое понятие было плохой идеей . строковая обработка UTF-16 является существенно иной, чем простая строковая обработка ASCII/MBCS. При использовании тех же алгоритмов/функций с ними обоими (это - то, на основе чего идея TCHAR!), Вы получаете очень плохую производительность на версии UTF-16 при выполнении немного больше, чем конкатенация простой строки (как парсинг и т.д.). Главная причина Суррогаты .

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

Если Вы задаетесь вопросом, все еще ли это на практике, то да - это все еще используется вполне немного. Никто не посмотрит на Ваш код, забавный, если он будет использовать TCHAR и _T (""). Проект я продолжаю работать теперь, преобразовывает от ANSI до unicode - и мы идем портативное устройство (TCHAR) маршрут.

Однако...

Мой голос должен был бы забыть весь ANSI/UNICODE портативные макросы (TCHAR, _T (""), и все вызовы _tXXXXXX, и т.д....) и просто принять unicode везде. Я действительно не вижу точку того, чтобы быть портативным, если Вам никогда не будет нужна версия ANSI. Я использовал бы все функции широкого символа и типы непосредственно. Preprend все строковые литералы с L.

Да, абсолютно; по крайней мере, для _T макроса. Я не так уверен в материале широкого символа, все же.

причина, являющаяся, состоит в том, чтобы лучше поддерживать WinCE или другие нестандартные платформы Windows. Если Вы на 100% уверены, что Ваш код останется на NT, то можно, вероятно, просто использовать регулярные объявления струны до. Однако лучше склоняться к более гибкому подходу, поскольку намного легче к #define, что макрос далеко на платформе не-Windows по сравнению с прохождением через тысяч строк кода и добавления его везде в случае, если необходимо портировать некоторую библиотеку на Windows Mobile.

Я вынужден согласиться с Сашей. Основная предпосылка TCHAR / _T() / и т.д. заключается в том, что вы можете написать приложение, основанное на "ANSI", а затем волшебным образом придать ему поддержку Unicode, определив макрос. Но это основано на нескольких плохих предположениях:

Что вы активно создаете как MBCS, так и Unicode версии вашего программного обеспечения

Иначе вы поскользнетесь и будете использовать обычные char* строки во многих местах.

Что вы не используете обратные косые черты в литералах _T("...")

Если ваша "ANSI" кодировка не ISO-8859-1, то получаемые char* и wchar_t* литералы не будут представлять одни и те же символы.

Что строки UTF-16 используются так же, как строки "ANSI"

Это не так. Юникод вводит несколько понятий, которых нет в большинстве старых кодировок символов. Суррогаты. Объединение символов. Нормализация. Условные и чувствительные к языку правила кеширования.

И, возможно, самое главное - тот факт, что UTF-16 редко сохраняется на диске или передается через Интернет: UTF-8, как правило, предпочтительнее для внешнего представления.

Что ваше приложение не использует Интернет

(Это может быть верным предположением для вашего программного обеспечения, но...)

Интернет работает на UTF-8 и множестве более редких кодировок. Концепция TCHAR распознает только две: "ANSI" (которая не может быть UTF-8) и "Unicode" (UTF-16). Это может быть полезно для того, чтобы сделать вызовы API Windows поддерживающими Unicode, но это чертовски бесполезно для того, чтобы сделать ваши веб-приложения и приложения электронной почты поддерживающими Unicode.

Что вы не используете никаких не-Microsoft библиотек

Никто больше не использует TCHAR. Poco использует std::string и UTF-8. SQLite имеет UTF-8 и UTF-16 версии своего API, но не имеет TCHAR. TCHAR даже нет в стандартной библиотеке, поэтому нет std::tcout, если вы не хотите определить его самостоятельно.

Что я рекомендую вместо TCHAR

Забудьте о существовании кодировок "ANSI", за исключением случаев, когда вам нужно прочитать файл, который не является действительным UTF-8. Забудьте и о TCHAR. Всегда вызывайте "W" версию функций Windows API. #define _UNICODE просто для того, чтобы убедиться, что вы случайно не вызовете функцию "A".

Всегда используйте кодировку UTF для строк: UTF-8 для char строк и UTF-16 (в Windows) или UTF-32 (в Unix-подобных системах) для wchar_t строк. typedef UTF16 и UTF32 типы символов, чтобы избежать различий между платформами.

Просто добавлю к старому вопросу:

НЕТ

Начните новый проект CLR C ++ в VS2010. Сами Microsoft используют L "Hello World" , - сказал Нуфф.

В статье Введение в программирование Windows на MSDN говорится

, что новые приложения всегда должны вызывать версии Unicode (API).

Макросы TEXT и TCHAR сегодня менее полезны, потому что все приложения должны использовать Unicode.

Я бы придерживался wchar_t и L "" .

ИМХО, если в вашем коде есть TCHAR, вы работаете на неправильном уровне абстракции.

Используйте любой тип строки, который наиболее удобен для вас при работе с текстом — мы надеемся, что это будет что-то, поддерживающее юникод, но это на ваше усмотрение. При необходимости выполните преобразование на границах API ОС.

При работе с путями к файлам придумайте свой собственный тип вместо использования строк. Это позволит вам использовать независимые от ОС разделители путей, даст вам более простой интерфейс для кода, чем ручная конкатенация и разделение строк, и будет намного проще адаптироваться к различным ОС (ansi, ucs-2, utf-8, что угодно) .