Я новачок у програмуванні 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.

Що ви не використовуєте бібліотеки, що не належать Microsoft

Більше ніхто не використовує 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 тощо ...) і просто взяти 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 .

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 як внутрішнє кодування та зберігати тексти у символьних рядках або std :: string. І приховайте їх до UTF-16 під час виклику WinAPI. Зараз UTF-8 є домінуючим кодуванням, і існує безліч зручних бібліотек та інструментів для обробки рядків UTF-8.

Перегляньте цей чудовий веб-сайт для більш детального читання: http://utf8everywhere.org/

Так, абсолютно; принаймні для макросу _T. Однак я не настільки впевнений у широкоформатних речах.

Причиною є краща підтримка WinCE або інших нестандартних платформ Windows. Якщо ви на 100% впевнені, що ваш код залишиться на NT, тоді ви, ймовірно, можете просто використовувати звичайні декларації C-рядків. Однак найкраще схилятися до більш гнучкого підходу, оскільки набагато простіше #define той макрос на платформі, що не є Windows, порівняно з переглядом тисяч рядків коду та додаванням його скрізь, якщо вам потрібно перенести якусь бібліотеку на мобільний.

ІМХО, якщо у вашому коді є TCHAR, ви працюєте на неправильному рівні абстракції.

Використовуйте будь-який тип рядка, який є найбільш зручним для вас, коли маєте справу з обробкою тексту - сподіваємось, це буде щось, що підтримує Unicode, але це залежить від вас. За необхідності виконайте перетворення на межі API 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 API як засіб для впровадження підтримки програм UTF-8. Якщо кодова сторінка ANSI налаштована для UTF-8, API API працює в UTF-8.