Frage

Ich bin neu in der Windows-Programmierung und nach dem Petzold Buch zu lesen, frage ich mich:

ist es immer noch ein gute Praxis, den TCHAR Typen und die _T() Funktion zu verwenden Strings zu erklären oder, wenn ich nur den wchar_t und L"" Strings in neuem Code verwenden sollte?

Ich werde Ziel nur Windows 2000 und höher und mein Code wird i18n von dem Start .

War es hilfreich?

Lösung

Ich würde immer noch die TCHAR-Syntax verwenden, wenn ich heute ein neues Projekt zu tun. Es gibt nicht viel praktischen Unterschied zwischen ihn und der WCHAR Syntax und I-Code bevorzugen, die in dem, was Art ist der Charakter explizit ist. Da die meisten API-Funktionen und Hilfsobjekte nehmen / TCHAR-Typen verwenden (z .: CString), macht es nur Sinn, es zu benutzen. Außerdem gibt es Ihnen Flexibilität, wenn Sie den Code in einem ASCII-App irgendwann entscheiden, zu verwenden, oder, wenn Windows jemals entwickelt sich zu Unicode32, etc.

Wenn Sie den WCHAR Weg zu gehen, würde ich es explizit sein. Das heißt, verwenden CStringW statt CString und Makros Gießen wenn auf TCHAR zu konvertieren. (ZB: CW2CT)

Das ist meiner Meinung nach jedenfalls.

Andere Tipps

Die kurze Antwort:. NO

Wie alle anderen schon geschrieben hat, verwenden viele Programmierer immer noch TCHARs und die entsprechenden Funktionen. In meiner bescheidenen Meinung nach das ganze Konzept war eine schlechte Idee, . UTF-16 String-Verarbeitung ist ganz anders als einfache ASCII / MBCS-String wird bearbeitet. Wenn Sie die gleichen Algorithmen / Funktionen mit beide verwenden (das ist, was die TCHAR Idee basiert auf!), Bekommt man sehr schlechte Leistung auf der UTF-16-Version, wenn Sie ein wenig mehr als einfache String-Verkettung tun (wie Parsen etc.). Der Hauptgrund dafür sind Surrogates .

Mit der einzigen Ausnahme, wenn Sie auf wirklich Ihre Anwendung für ein System erstellen, die Unicode nicht unterstützt Ich sehen keinen Grund dieses Gepäck aus der Vergangenheit in einer neuen Anwendung zu nutzen.

Ich habe mit Sascha zu vereinbaren. Die zugrunde liegende Prämisse der TCHAR / _T() / usw. ist, dass Sie eine „ANSI“ -basierte Anwendung können schreiben und sie dann auf magische Weise Unicode-Unterstützung geben, indem ein Makro zu definieren. Aber das beruht auf mehreren schlechten Annahmen:

dass Sie aktiv sowohl MBCS und Unicode-Versionen Ihrer Software bauen

Ansonsten Sie wird Ausrutscher und verwendet gewöhnliche char* Strings in vielen Orten.

Dass Sie keine Nicht-ASCII Backslash verwenden entkommt in _T ( "...") Literalen

Wenn Ihr "ANSI" encoding geschieht ISO-8859-1 zu sein, ist die resultierende char* und wchar_t* Literale werden nicht die gleichen Zeichen darstellen.

, die UTF-16-Strings werden wie "ANSI" Strings

verwendet

Sie sind es nicht. Unicode stellt verschiedene Konzepte, die in den meisten älteren Zeichenkodierungen sind nicht vorhanden. Surrogates. Die Kombination von Zeichen. Normalisierung. Bedingte und sprachsensitiven Gehäuse Regeln.

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

.

, dass Ihre Anwendung nicht auf das Internet verwendet

(Nun, dies kann eine gültige Annahme sein für Ihre Software, aber ...)

Die Bahn läuft auf UTF-8 und eine Fülle von seltener Codierungen . Das TCHAR Konzept erkennt nur zwei: „ANSI“ (was nicht UTF-8 ) und "Unicode" (UTF-16). Es kann für die Herstellung Ihrer Windows-API-Aufrufe Unicode-aware nützlich sein, aber es ist für die Herstellung Ihrer Web- und E-Mail-Apps Unicode-aware nutzlos verdammt.

, dass Sie keine Nicht-Microsoft-Bibliotheken verwenden

Niemand sonst verwendet TCHAR. Poco verwendet std::string und UTF-8. SQLite UTF-8 und UTF-16-Versionen seiner API hat, aber kein TCHAR. TCHAR ist nicht einmal in der Standard-Bibliothek, so dass keine std::tcout es sei denn, wollen Sie es selbst definieren.

Was ich empfehlen, statt TCHAR

Vergessen Sie, dass „ANSI“ Kodierungen existieren, außer wenn Sie eine Datei lesen müssen, die nicht gültig UTF-8 ist. Vergessen Sie TCHAR auch. Rufen Sie immer die „W“ -Version von Windows-API-Funktionen. #define _UNICODE nur sicherstellen, dass Sie nicht versehentlich eine „A“ Funktion nennen.

UTF-8 für char Strings und UTF-16 (unter Windows) oder UTF-32 (auf Unix-ähnlichen Systemen) für wchar_t Strings:

Immer UTF-Kodierungen für Strings verwenden. typedef UTF16 und UTF32 Charaktertypen zu Plattform Unterschiede zu vermeiden.

Wenn Sie sich fragen, ob es noch in der Praxis ist, dann ja - es ist immer noch ziemlich viel verwendet. Niemand wird auf den Code komisch aussehen, wenn es TCHAR und _T ( „“) verwendet. Das Projekt arbeite ich auf jetzt von ANSI in Unicode konvertieren -. Und wir werden die tragbare (TCHAR) Route

Jedoch ...

Meine Stimme wäre alle ANSI / UNICODE tragbares Makros zu vergessen (TCHAR, _T ( "") und alle _tXXXXXX nennen, etc ...) und nur Unicode überall annehmen. Ich sehe nicht den Punkt wirklich tragbar zu sein, wenn Sie nie eine ANSI-Version benötigen. Ich würde verwenden, um alle Breitzeichen Funktionen und Typen direkt. Preprend alle Stringliterale mit einem L.

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

  

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

     

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

Ich würde halten Sie sich an wchar_t und L"".

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

Um es zusammenzufassen, verwenden char * und std :: string, UTF-8-Codierung angenommen, und tun, um die Conversions zu UTF-16 nur dann, wenn API-Funktionen gewickelt wird.

Weitere Informationen und Rechtfertigung für diesen Ansatz in Windows-Programme können in http://www.utf8everywhere.org .

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

Alle diese TCHAR / WCHAR Sachen gibt es wegen der historischen Gründen. TCHAR stellt eine seemly ordentliche Weise (Verkleidung) zwischen ANSI Textkodierung (MBCS) zu schalten und Unicode Textkodierung (UTF-16). In der Vergangenheit haben die Menschen nicht ein Verständnis für die Anzahl der Zeichen aller Sprachen der Welt. Sie geht davon aus 2 Bytes genug waren, um alle Zeichen zu repräsentieren und somit ein festes Länge Zeichencodierungsschema unter Verwendung von WCHAR aufweist. Dies ist jedoch nicht mehr der Fall nach der Veröffentlichung von Unicode 2.0 in 1996 .

Das heißt: Egal, welche Sie verwenden in CHAR / WCHAR / TCHAR, der Textverarbeitungsteil in Ihrem Programm soll in der Lage sein zu handhaben variabler Länge Zeichen für die Internationalisierung.

Sie müssen also tatsächlich mehr tun, als man von CHAR / WCHAR / TCHAR für die Programmierung unter Windows die Wahl:

  1. Wenn Ihre Anwendung klein ist und nicht die Textverarbeitung beinhaltet (das heißt vorbei direkt um die Textzeichenfolge als Argumente), dann hält mit WCHAR. Da es einfacher ist, auf diese Weise mit WinAPI mit Unicode-Unterstützung zu arbeiten.
  2. Sonst würde ich vorschlagen, UTF-8 als interne Codierung und Speicherung von Texten in char Strings oder std :: string verwenden. Und verdeckte sie in UTF-16, wenn WinAPI aufrufen. UTF-8 ist jetzt die dominierende Codierung und es gibt viele praktische Bibliotheken und Tools Prozess UTF-8-Strings.

Sehen Sie sich diese wunderbare Website für weitergehende Literatur: http://utf8everywhere.org/

Ja, absolut; zumindest für den _T Makro. Ich bin mir nicht so sicher über die Breitzeichen Sachen, though.

Der Grund dafür ist eine bessere Unterstützung WinCE oder andere Nicht-Standard-Windows-Plattformen. Wenn Sie 100% sicher, dass Ihr Code auf NT bleiben, dann können Sie wahrscheinlich nur regelmäßige Erklärungen C-String verwenden. Allerdings ist es am besten auf dem flexibleren Ansatz zu neigen, da es viel einfacher ist, dass die Makro #define auf einer Nicht-Windows-Plattform im Vergleich entfernt, um Tausende von Zeilen Code durchlaufen und das Hinzufügen es überall im Fall, dass Sie in dem Hafen einig Bibliothek auf Windows Mobile.

IMHO, wenn es TCHARs in Ihrem Code ist, sind Sie auf der falschen Ebene der Abstraktion arbeiten.

Mit was String-Typ für Sie am bequemsten ist, wenn sie mit Textverarbeitung zu tun - das wird hoffentlich etwas sein, Unicode-Unterstützung, aber das ist bis zu Ihnen. Hat Umwandlung bei OS API Grenzen wie nötig.

Wenn Sie mit Dateipfaden zu tun, Peitsche Ihre eigene Art anstelle von Strings auf. Dadurch werden Sie OS-unabhängigen Weg Separatoren ermöglichen, werden Sie eine einfachere Schnittstelle zu Code geben vor als die manuelle String-Verkettung und Spalten, und wird viel einfacher sein, sich anzupassen an verschiedene Betriebssysteme (ansi, UCS-2, UTF-8, was auch immer) .

Die einzigen Gründe sehe ich etwas anderes als die explizite WCHAR zu verwenden sind Portabilität und Effizienz.

Wenn Sie Ihre endgültige ausführbare so klein wie möglich Gebrauch char machen.

Wenn Sie nicht über RAM-Auslastung kümmern und Internationalisierung wollen so einfach wie einfache Übersetzung sein, verwenden WCHAR.

Wenn Sie Ihren Code flexibel machen, verwenden Sie TCHAR.

Wenn Sie nur über die Verwendung der lateinischen Buchstaben planen, könnten Sie auch verwenden, um die ASCII / MBCS-Strings, so dass Ihre Benutzer nicht so viel RAM benötigen.

Für Menschen, die „i18n von Anfang up“, sparen Sie sich den Quellcode Raum sind und einfach alle Unicode-Funktionen verwenden.

Nur das Hinzufügen zu einer alten Frage:

NO

Gehen Sie ein neues CLR C ++ Projekt in VS2010 starten. Microsoft selbst L"Hello World" verwenden, ‚nuff said.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top