Запуск нового приложения Windows: я должен использовать _TCHAR или wchar_t для текста?

Question

Я пишу новое (личное хобби) приложение для Windows на С ++.

В предыдущих низкоуровневых приложениях для Windows я использовал _TCHAR (или просто TCHAR) массивы / basic_strings для работы со строками.

Есть ли какое-либо преимущество в использовании _TCHAR по сравнению с прямым Unicode с wchar_t, , если мне не нужны платформы Windows до Win2k ?

---

edit: после отправки я обнаружил похожий вопрос здесь с октября 2008 года:

TCHAR все еще актуален?

Кажется, сейчас больше консенсуса в отношении отказа от чар

Answer 1

нет там нет. Просто зайдите с wchar_t.

TCHAR полезен, только если вы хотите использовать переключатель условной компиляции для преобразования вашей программы для работы в режиме ASCII. Поскольку Windows 2000 и выше являются платформами Unicode, этот переключатель не предоставляет никакого значения. Вместо этого вы намекаете другим разработчикам в вашем проекте, что ASCII была допустимой целью, хотя на самом деле это не так.

Answer 2

wchar_t является определенным типом c ++, то есть 16 битами в Visual Studio, но 32 битами в различных компиляторах gcc. Он всегда способен удерживать код Unicode.

TCHAR и _TCHAR не являются символами "Юникод" - они предназначены для использования в коде, который может быть скомпилирован и / или использован в программах Юникод ИЛИ Ansi:

_TCHAR - от его основного подчеркивания - расширение библиотеки времени выполнения Microsoft C до стандарта c ++. _TCHAR будет, когда определено _UNICODE, 16-битным символом, когда определено _MBCS, многобайтовым символом, а когда ни один из них не определен, будет однобайтовым символом. Используйте этот тип, если вы используете строковые функции, определенные в MS CRT с префиксом _t: например, _tcscpy() является заменой strcpy() / wcscpy().

TCHAR определяется Win32 API. Этот тип - CHAR, когда UNICODE не определен, и WCHAR, когда UNICODE определено (обратите внимание на отсутствие подчеркивания для этого типа). Функции Windows API, которые принимают строки, также ожидают WCHAR строк в UNICODE сборках и CHAR строк в сборках не в Юникоде.

Подведем итог:

• wchar_t - это кроссплатформенный определенный C ++ тип, который может содержать кодовую точку Unicode - на компиляторах, отличных от Microsoft, часто имеет ширину 32 бита.
• _TCHAR - это определенный Microsoft тип, который связан с _tcs* c исполняющими функциями, которые изменяют свой тип на основе определения _UNICODE и / или _MBCS.
• TCHAR - это определенный в Windows API тип, который меняет свой тип на основе определения (или нет) UNICODE.
• WCHAR - это собственный тип Windows API для работы со строками Unicode. При использовании набора инструментов GCC для создания кода Windows ширина будет 16 бит, где wchar_t может и не быть.

Это помогает? Я не знаю.

Answer 3

Я бы пошел с простой wchar_t

Преимущество TCHAR состоит в том, что он позволяет включать и выключать Юникод, и ваш код, обращающийся к Windows API, будет работать.

Проблема в том, что никакой другой API его не примет.

std::cout будет подавлен std :: wstring , std :: string будет подавлен при инициализации wchar_t* и т. Д.

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

И поскольку совместимость с не-Unicode была проблемой только в Windows 95, поддерживать их больше нет смысла. Включите Unicode, используйте wchar_t и избавьте себя от головной боли.

Конечно, чтобы избежать путаницы, вы можете также вызывать * W-версии функций Win32. Вместо CreateWindow, например, CreateWindowW, так что даже если кто-то скомпилирует ваш код с отключенным Юникодом в настройках проекта, он все равно будет работать. Если вы собираетесь использовать жесткий код для поддержки Unicode, вы можете сделать это последовательно.

Answer 4

Если вы всегда компилируете свое приложение для Unicode во время его разработки, ЭТО НЕ БУДЕТ РАБОТАТЬ при компиляции для строк ANSI, даже если оно заполнено полями TCHAR. (За исключением игрушечных приложений.)

Вот к чему привел ДжаредПар, когда сказал, что ANSI не является допустимой целью. Если вы хотите поддерживать версии Unicode и ANSI, вы можете использовать TCHAR для этого, но простое использование TCHAR и других T не приведет вас туда - вы должны активно создавать и поддерживать обе версии. Определенно не стоит больше для большинства приложений.

Answer 5

Используйте TCHAR. Он открывает ваше приложение для сценариев развертывания как UNICODE, так и не UNICODE. Конечно, больше проблем с цепочечными разговорами и использованием стандартных функций манипуляции со строками.