Я новичок в программировании 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, если вы делаете немного больше, чем простое конкатенация строк (например, разбор и т.д.). Основная причина Surrogates.
С единственным исключением, когда вы действительно должны скомпилировать свое приложение для системы, которая не поддерживает Unicode, я не вижу причин использовать этот багаж из прошлого в новом приложении.
Я должен согласиться с Сашей. Основополагающая предпосылка TCHAR/_T()/и т.д. Заключается в том, что вы можете написать приложение на основе ANSI и затем магически дать ему поддержку Unicode, указав макрос. Но это основано на нескольких плохих предположениях:
Чтобы вы активно строили как версии MBCS, так и Unicode вашего программного обеспечения
В противном случае вы будете скользить и использовать обычные строки char* во многих местах.
Чтобы вы не использовали escape-образы без использования 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.
Чтобы вы не использовали библиотеки, отличные от Microsoft
Никто не использует TCHAR. Poco использует std::string и UTF-8. SQLite имеет UTF-8 и UTF-16 версии своего API, но не TCHAR. TCHAR даже не в стандартной библиотеке, поэтому no std::tcout, если вы не хотите сами определить его.
Забудьте, что существуют кодировки 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, чтобы избежать различий в платформе.
Если вам интересно, все ли это на практике, тогда да - он все еще используется совсем немного. Никто не будет смотреть на ваш код смешно, если он использует TCHAR и _T (""). Проект, над которым я сейчас работаю, преобразуется из ANSI в unicode - и мы отправляемся на переносимый (TCHAR) маршрут.
Однако...
Мое голосование будет состоять в том, чтобы забыть все переносные макросы ANSI/UNICODE (TCHAR, _T ("") и все вызовы _tXXXXXX и т.д.) и просто предполагать unicode везде. Я действительно не вижу смысла быть портативным, если вам никогда не понадобится версия 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.
Да, абсолютно; по крайней мере, для макроса _T. Однако я не настолько уверен в вещах с широким характером.
Причина заключается в том, чтобы лучше поддерживать WinCE или другие нестандартные платформы Windows. Если вы на 100% уверены, что ваш код останется на NT, тогда вы, вероятно, можете просто использовать регулярные объявления C-строк. Тем не менее, лучше всего стремиться к более гибкому подходу, поскольку гораздо проще # определить этот макрос на платформе, отличной от Windows, по сравнению с прохождением через тысячи строк кода и добавлением его повсюду, если вам нужно выгрузить некоторую библиотеку для Windows Mobile.
TCHAR/WCHAR может быть достаточно для некоторых старых проектов. Но для новых приложений я бы сказал НЕТ.
Все эти материалы TCHAR/WCHAR существуют по историческим причинам. TCHAR обеспечивает кажущийся опрятный способ (маскировка) для переключения между текстовым кодированием ANSI (MBCS) и кодировкой текста Unicode (UTF-16). Раньше у людей не было понимания количества персонажей всех языков мира. Они предположили, что 2 байта были достаточными для представления всех символов и, таким образом, с использованием схемы кодирования с фиксированной длиной, использующей WCHAR. Однако это уже не так после выпуска Unicode 2.0 в 1996.
То есть: Независимо от того, что вы используете в CHAR/WCHAR/TCHAR, часть обработки текста в вашей программе должна обрабатывать символы переменной длины для интернационализации.
Таким образом, вам действительно нужно сделать больше, чем выбрать один из CHAR/WCHAR/TCHAR для программирования в Windows:
Ознакомьтесь с этим замечательным веб-сайтом для более глубокого чтения: http://utf8everywhere.org/
ИМХО, если в коде есть TCHAR, вы работаете на неправильном уровне абстракции.
Используйте любой тип строки, наиболее удобный для вас при работе с текстовой обработкой - это, надеюсь, будет чем-то, что поддерживает unicode, но это зависит от вас. Преобразование на границах API OS при необходимости.
При работе с файловыми путями, вместо использования строк, используйте собственный собственный тип. Это позволит вам независимые от ОС разделители путей, даст вам более простой интерфейс для кода, чем ручной конкатенации строк и разделения, и будет намного легче адаптироваться к различным операционным системам (ansi, ucs-2, utf-8, что угодно).
Единственные причины, по которым я вижу использование чего-либо, кроме явного WCHAR, - это мобильность и эффективность.
Если вы хотите сделать свой окончательный исполняемый файл как можно меньшим, используйте char.
Если вы не заботитесь об использовании ОЗУ и хотите, чтобы интернационализация была так же проста, как простой перевод, используйте WCHAR.
Если вы хотите сделать свой код гибким, используйте TCHAR.
Если вы планируете использовать только латинские символы, вы можете также использовать строки ASCII/MBCS, чтобы ваш пользователь не нуждался в таком количестве ОЗУ.
Для людей, которые "i18n с самого начала", сохраните пространство исходного кода и просто используйте все функции Unicode.
Просто добавив старый вопрос:
Запустите новый проект CLR С++ в VS2010. Microsoft использует L"Hello World", сказал nuff.