Ist TCHAR noch relevant?

Ich bin neu in der Windows-Programmierung und nachdem ich das Petzold-Buch gelesen habe, frage ich mich:

ist es immer noch gute Praxis, die zu verwenden TCHAR Typ und die _T() Funktion zum Deklarieren von Strings oder ob ich nur die verwenden sollte wchar_t und L"" Zeichenfolgen in neuem Code?

Ich werde nur auf Windows 2000 und höher abzielen, und mein Code wird sein i18n von Anfang an.

Die kurze Antwort: NEIN.

Wie alle anderen bereits geschrieben haben, verwenden viele Programmierer immer noch TCHARs und die entsprechenden Funktionen. Meiner bescheidenen Meinung nach Das ganze Konzept war eine schlechte Idee. UTF-16 Die String-Verarbeitung unterscheidet sich stark von der einfachen ASCII/MBCS-String-Verarbeitung. Wenn Sie mit beiden dieselben Algorithmen/Funktionen verwenden (darauf basiert die TCHAR-Idee!), erhalten Sie eine sehr schlechte Leistung in der UTF-16-Version, wenn Sie etwas mehr als eine einfache Zeichenfolgenverkettung (wie z parsen usw.). Der Hauptgrund sind Ersatz.

Mit der einzigen Ausnahme, wenn Sie Ja wirklich Ihre Anwendung für ein System kompilieren müssen, das Unicode nicht unterstützt. Ich sehe keinen Grund, diesen Ballast aus der Vergangenheit in einer neuen Anwendung zu verwenden.

Da muss ich Sascha zustimmen. Die zugrunde liegende Prämisse von TCHAR / _T() / etc. ist, dass Sie eine “ANSI”-basierte Anwendung schreiben und ihr dann auf magische Weise Unicode-Unterstützung geben können, indem Sie ein Makro definieren. Dies basiert jedoch auf mehreren schlechten Annahmen:

Dass Sie sowohl MBCS- als auch Unicode-Versionen Ihrer Software aktiv erstellen

Ansonsten du Wille ausrutschen und normal verwenden char* Saiten an vielen Stellen.

Dass Sie in _T(“…”)-Literalen keine Nicht-ASCII-Backslash-Escapezeichen verwenden

Sofern Ihre “ANSI” -Codierung nicht zufällig ISO-8859-1 ist, ist das Ergebnis char* und wchar_t* Literale repräsentieren nicht die gleichen Zeichen.

Dass UTF-16-Strings genauso wie “ANSI”-Strings verwendet werden

Sie sind nicht. Unicode führt mehrere Konzepte ein, die in den meisten älteren Zeichencodierungen nicht vorhanden sind. Ersatz. Zeichen kombinieren. Normalisierung. Bedingte und sprachabhängige Groß- und Kleinschreibung.

Und vielleicht am wichtigsten ist die Tatsache, dass UTF-16 selten auf der Festplatte gespeichert oder über das Internet gesendet wird: UTF-8 wird tendenziell für die externe Darstellung bevorzugt.

Dass Ihre Anwendung nicht das Internet verwendet

(Nun, dies kann eine gültige Annahme für sein dein software, aber…)

Das Web läuft auf UTF-8 und eine Fülle seltener Kodierungen. Die TCHAR Das Konzept kennt nur zwei: “ANSI” (was kippen B. UTF-8) und “Unicode” (UTF-16) sein. Es kann nützlich sein, um Ihre Windows-API-Aufrufe Unicode-fähig zu machen, aber es ist verdammt nutzlos, Ihre Web- und E-Mail-Apps Unicode-fähig zu machen.

Dass Sie keine Nicht-Microsoft-Bibliotheken verwenden

Niemand sonst verwendet TCHAR. Poko Verwendet std::string und UTF-8. SQLite hat UTF-8- und UTF-16-Versionen seiner API, aber nein TCHAR. TCHAR ist nicht einmal in der Standardbibliothek, also nein std::tcout Es sei denn, Sie möchten es selbst definieren.

Was ich anstelle von TCHAR empfehle

Vergessen Sie, dass “ANSI”-Kodierungen existieren, außer wenn Sie eine Datei lesen müssen, die kein gültiges UTF-8 ist. Vergessen TCHAR zu. Rufen Sie immer die “W”-Version von Windows-API-Funktionen auf. #define _UNICODE Nur um sicherzustellen, dass Sie nicht versehentlich eine “A” -Funktion aufrufen.

Verwenden Sie immer UTF-Codierungen für Zeichenfolgen: UTF-8 für char Zeichenfolgen und UTF-16 (unter Windows) oder UTF-32 (auf Unix-ähnlichen Systemen) für wchar_t Saiten. typedef UTF16 und UTF32 Zeichentypen, um Plattformunterschiede zu vermeiden.

Wenn Sie sich fragen, ob es noch in der Praxis ist, dann ja – es wird immer noch ziemlich viel verwendet. Niemand wird Ihren Code komisch ansehen, wenn er TCHAR und _T(“”) verwendet. Das Projekt, an dem ich gerade arbeite, konvertiert von ANSI nach Unicode – und wir gehen den Weg der Portabilität (TCHAR).

Aber…

Meine Stimme wäre, alle tragbaren ANSI/UNICODE-Makros (TCHAR, _T(“”) und alle _tXXXXXX-Aufrufe usw. zu vergessen und einfach überall Unicode anzunehmen. Ich sehe wirklich keinen Sinn darin, portabel zu sein, wenn Sie niemals eine ANSI-Version benötigen. Ich würde alle Wide-Character-Funktionen und -Typen direkt verwenden. Stellen Sie allen Zeichenfolgenliteralen ein L voran.

Ich würde immer noch die TCHAR-Syntax verwenden, wenn ich heute ein neues Projekt machen würde. Es gibt keinen großen praktischen Unterschied zwischen der Verwendung und der WCHAR-Syntax, und ich bevorzuge Code, der den Zeichentyp explizit angibt. Da die meisten API-Funktionen und Hilfsobjekte TCHAR-Typen annehmen/verwenden (z. B.: CString), ist es einfach sinnvoll, sie zu verwenden. Außerdem gibt es Ihnen Flexibilität, wenn Sie sich irgendwann entscheiden, den Code in einer ASCII-App zu verwenden, oder wenn Windows jemals zu Unicode32 weiterentwickelt wird usw.

Wenn Sie sich für die WCHAR-Route entscheiden, würde ich das ausdrücklich sagen. Das heißt, verwenden Sie CStringW anstelle von CString und wandeln Sie Makros um, wenn Sie in TCHAR konvertieren (z. B.: CW2CT).

Das ist jedenfalls meine Meinung.

Die Artikel Einführung in die Windows-Programmierung auf MSDN sagt

Neue Anwendungen sollten immer die Unicode-Versionen (der API) aufrufen.

Die TEXT und TCHAR Makros sind heute weniger nützlich, da alle Anwendungen Unicode verwenden sollten.

Ich würde mich daran halten wchar_t und L"".

Ich möchte einen anderen Ansatz vorschlagen (keiner von beiden).

Zusammenfassend verwenden Sie char* und std::string unter der Annahme einer UTF-8-Codierung, und führen Sie die Konvertierungen in UTF-16 nur beim Umschließen von API-Funktionen durch.

Weitere Informationen und Begründungen für diesen Ansatz in Windows-Programmen finden Sie in http://www.utf8everywhere.org.

TCHAR/WCHAR könnte für einige Legacy-Projekte ausreichen. Aber für neue Anwendungen, würde ich sagen NEIN.

All diese TCHAR/WCHAR Sachen gibt es aus historischen Gründen. TCHAR bietet eine scheinbar saubere Möglichkeit (Tarnung), zwischen ANSI-Textcodierung (MBCS) und Unicode-Textcodierung (UTF-16) zu wechseln. In der Vergangenheit hatten die Menschen kein Verständnis für die Anzahl der Schriftzeichen aller Sprachen der Welt. Sie gingen davon aus, dass 2 Bytes ausreichten, um alle Zeichen darzustellen und somit ein Zeichencodierungsschema mit fester Länge zu verwenden WCHAR. Dies gilt jedoch nicht mehr nach der Veröffentlichung von Unicode 2.0 in 1996.

Das heißt: Egal welche Sie verwenden CHAR/WCHAR/TCHARsollte der Textverarbeitungsteil in Ihrem Programm verarbeiten können Zeichen mit variabler Länge für die Internationalisierung.

Sie müssen also tatsächlich mehr tun, als sich für eines zu entscheiden CHAR/WCHAR/TCHAR für die Programmierung unter Windows:

1. Wenn Ihre Anwendung klein ist und keine Textverarbeitung beinhaltet (dh nur die Textzeichenfolge als Argumente weitergibt), dann bleiben Sie dabei WCHAR. Da es auf diese Weise einfacher ist, mit WinAPI mit Unicode-Unterstützung zu arbeiten.
2. Andernfalls würde ich vorschlagen, UTF-8 als interne Codierung zu verwenden und Texte in Zeichenketten oder std::string zu speichern. Und wandeln Sie sie beim Aufrufen von WinAPI in UTF-16 um. UTF-8 ist jetzt die vorherrschende Kodierung und es gibt viele praktische Bibliotheken und Tools, um UTF-8-Strings zu verarbeiten.

Schauen Sie sich diese wundervolle Website an, um mehr in die Tiefe zu lesen:
http://utf8everywhere.org/