Я новичок в программировании для Windows, и после прочтения книги Петцольда мне интересно:

это еще хорошая практика , чтобы использовать TCHARтип и _T()функцию , чтобы объявить строки или если я должен просто использовать wchar_tи L""строки в новом коде?

Я буду ориентироваться только на Windows 2000 и выше, и мой код будет i18n с самого начала.

Я бы все равно использовал синтаксис TCHAR, если бы сегодня делал новый проект. Между его использованием и синтаксисом WCHAR нет большой практической разницы, и я предпочитаю код, который явно указывает тип символа. Поскольку большинство функций API и вспомогательных объектов принимают / используют типы TCHAR (например, CString), имеет смысл использовать его. Кроме того, это дает вам гибкость, если вы в какой-то момент решите использовать код в приложении ASCII, или если Windows когда-либо перейдет на Unicode32 и т. Д.

Если вы решите пойти по маршруту WCHAR, я скажу об этом прямо. То есть используйте CStringW вместо CString и макросы приведения при преобразовании в TCHAR (например, CW2CT).

Во всяком случае, это мое мнение.

Короткий ответ: НЕТ .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако...

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

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

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

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

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

Я хотел бы предложить другой подход (ни один из двух).

Подводя итог, используйте char * и std :: string, предполагая кодировку UTF-8, и выполняйте преобразование в UTF-16 только при упаковке функций API.

Дополнительную информацию и обоснование этого подхода в программах Windows можно найти на http://www.utf8everywhere.org .

TCHAR/ WCHARможет быть достаточно для некоторых устаревших проектов. Но для новых приложений я бы сказал НЕТ .

Все эти TCHAR/ WCHARвещи есть в силу исторических причин. TCHARобеспечивает удобный способ (маскировку) переключения между кодировкой текста ANSI (MBCS) и кодировкой текста Unicode (UTF-16). В прошлом у людей не было представления о количестве символов всех языков мира. Они предположили, что 2 байта было достаточно для представления всех символов и, следовательно, с использованием схемы кодирования символов фиксированной длины WCHAR. Однако это больше не так после выпуска Unicode 2.0 в 1996 году .

То есть: независимо от того, что вы используете в CHAR/ WCHAR/ TCHAR, часть обработки текста в вашей программе должна иметь возможность обрабатывать символы переменной длины для интернационализации.

Таким образом, вам действительно нужно сделать больше, чем выбрать один из CHAR/ WCHAR/ TCHARдля программирования в Windows:

1. Если ваше приложение маленькое и не требует обработки текста (т.е. просто передает текстовую строку в качестве аргументов), придерживайтесь WCHAR. Так как с WinAPI так проще работать с поддержкой Unicode.
2. В противном случае я бы предложил использовать UTF-8 в качестве внутренней кодировки и хранить тексты в строках char или std :: string. И скрыть их в UTF-16 при вызове WinAPI. UTF-8 в настоящее время является доминирующей кодировкой, и существует множество удобных библиотек и инструментов для обработки строк UTF-8.

Посетите этот замечательный сайт для более подробного чтения: http://utf8everywhere.org/

Да, конечно; по крайней мере, для макроса _T. Однако я не уверен в том, что такое широкие символы.

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

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

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

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

Единственные причины, по которым я вижу использование чего-либо, кроме явного WCHAR, - это переносимость и эффективность.

Если вы хотите, чтобы конечный исполняемый файл был как можно меньше, используйте char.

Если вас не волнует использование ОЗУ и вы хотите, чтобы интернационализация была такой же простой, как простой перевод, используйте WCHAR.

Если вы хотите сделать свой код гибким, используйте TCHAR.

Если вы планируете использовать только латинские символы, вы также можете использовать строки ASCII / MBCS, чтобы вашему пользователю не требовалось столько оперативной памяти.

Для людей, которые "i18n с самого начала", сэкономьте место для исходного кода и просто используйте все функции Unicode.

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

Нет

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

TCHARимеют новое значение для переноса с WCHARна CHAR.

https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page

В последних выпусках Windows 10 кодовая страница ANSI и API-интерфейсы -A использовались как средство для внедрения поддержки UTF-8 в приложениях. Если кодовая страница ANSI настроена для UTF-8, -A API работают в UTF-8.