PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Typ "_TCHAR" in C++?


aths
2012-03-13, 11:13:29
Ich habe einen Quelltext den ich wegen einer NDA-Vereinbarung leider nicht posten darf. Wenn ich den Source kompilieren will, erhalte ich eine Fehlermeldung, dass "TCHAR" einen Fehler verursache. Ich poste mal die betreffende Zeile:

int _tmain(int argc, _TCHAR* argv[])

Visual C++ Express von Microsoft meckert bei der Zeile in der "_TCHAR" vorkommt, führt im Fehlerlog aber nur "TCHAR" auf. Kann ich einen anderen Typ nehmen den diese Programmiersprache kennt?

Ectoplasma
2012-03-13, 12:13:58
TCHAR ist ein Makro, welches entweder nach 'char' oder 'wchar_t' expandiert wird. Das hängt davon ab, ob du ein UNICODE Compilat haben willst oder nicht. Die Byte - Anzahl von 'wchar_t' ist compilerabhängig. Unter Windows sind das 2 Byte.

aths
2012-03-13, 14:28:50
Danke.

Gast
2012-03-13, 21:33:26
Meckern sollte er trotzdem nicht, der Typ / das Makro sollte über "tchar.h" gefunden werden:
#include <tchar.h>

Evtl. fehlen dir auch bestimmte Voraussetzungen fürs kompilieren? Windows-SDK oder sowas?
Ist schon ne Weile her, deshalb kann ich da nur ne Vermutung in den Raum werfen.

Gast
2012-04-22, 23:40:23
TCHAR ist ein Makro, welches entweder nach 'char' oder 'wchar_t' expandiert wird. Das hängt davon ab, ob du ein UNICODE Compilat haben willst oder nicht.Unicode verträgt sich in Form von UTF-8 auch prima mit Chars.

Ectoplasma
2012-04-23, 10:15:36
Unicode verträgt sich in Form von UTF-8 auch prima mit Chars.

Das ist richtig, solange du die Strings nur "durchschleiftst". Probleme gibt es aber, wenn du die Länge des String bestimmen musst, oder den String einlesen oder anzeigen musst, da UTF-8 eine variable Zahl von Bytes haben kann. Ein 'strlen' versagt schonmal, wenn du nicht die Byte-Anzahl, sondern die Character-Anzahl haben möchtest. Naja, das wirst du ja selber wissen. Man muss aber darauf hinweisen, dass der Umgang mit UTF-8 eben etwas mehr Aufmerksamkeit erfordert. Das Gleiche gilt übrigens auch für UTF-16. UTF-32 ist Problemfrei. Windows selbst hat nur einen alten UNICODE Standard bei dem man fest 2 Bytes verwendet.

Gast
2012-04-26, 22:55:50
Ich dachte MS wäre von UCS-2 dann letztendlich zu UTF-16 geswitcht, also ebenfalls eine Kodierung variabler Länge?

UTF-32 hat das Problem zwar nicht, aber dafür enorme Speicheranforderungen und die üblichen Endianness-Probleme.

Das alles hat man bei UTF-8 nicht. Ordentliches Unicode-Handling ist aber so aufwändig, dass man mit keiner der verfügbaren Kodierungen die Länge eines Strings in Zeichen mit einer Funktion der Klasse strlen bestimmen kann. Siehe entsprechende LIbraries wie ICU.

UTF-8 hat den Vorteil, dass es Zeichen des ASCII-Zeichensatzes mti einem Byte darstellen kann und für die gängigsten Dnge (oft interessiert mich ja auch einfach nur die Größe in Bytes) genauso behandelt werden kann wie "normale" nullterminierte ASCII-Strings. Nur wenn man den Inhalt auch selbst interpretieren (und nicht nur verarbeiten) will, hat man hier einen Mehraufwand. Einlesen oder Anzeigen ist aber kein Problem.

Dafür hat man keinerlei Probleme mit der Endianess und BOMs. UTF-16 hingegen vereint sozusagen das schlechteste aus beiden Welten. Variable Länge, Endianness-abhängig und ASCII-inkompatibel.

Ich kann nur erahnen, wie sich die UTF-16-Nutzer damals gefühlt haben müssen, als das Unicode-Konsortium sich dazu entschied, den Raum der gültigen Zeichen auf mehr als die bis dahin verwendeten 16 Bits zu erweitern, während man bis dato davon ausging, dass man hier eine Kodierung fester Länge hat, mit der man alle Unicode-Cdepoints darstellen kann. Ich denke mal die Entscheidung pro UCS-2/UTF-16 fiel bei Microsoft, Sun (bei Java) und anderen genau unter dieser Annahme. Wäre es tatsächlich dabei geblieben, wäre das wohl auch eine der vernünftigeren Lösungen gewesen.

Ectoplasma
2012-04-27, 09:57:22
Wass soll ich sagen, volle Zustimmung. Ich selbst entwickle meine Software auch nur noch mit UTF-8. Ist zwar etwas aufwändiger unter Windows, aber ansonsten die portabelste Lösung aus meiner Sicht.

Das Windows (ab Vista?) auf UTF-16 umgestiegen ist, habe ich so noch nicht bemerkt, will es aber nicht ausschließen. Das dürfte hier und dort böse Effekte verursachen.