Kompatibilität von LPCTSTR und std::string
-
Also std::string und std::wstring gibts immer, unabhängig davon ob TCHAR nu char oder wchar_t ist. Bloss verwendet std::string immer char und std::wstring immer wchar_t. Du kannst aber z.B. immer den Output von std::string::c_str an MessageBoxA übergeben und den Output von std::wstring::c_str an MessageBoxW übergeben.
Es kommt halt sehr darauf an was du machen willst. Manchmal ist es die einfachste und beste Lösung einfach auf std::string zu verzichten und nur std::wstring zu verwenden, dann wieder gibt es Fälle wo es besser ist einfach beides zu implementieren, also eine Funktion die std::string frisst und eine die std::wstring frisst. Und manchmal kann es auch Sinnvoll sein eben TCHAR zu verwenden.
-
Wo könnte es denn einen Nachteil geben, wenn ich immer wstring benutze?
-
Wenn du z.B. Libraries/APIs verwenden willst die bloss ANSI Interfaces haben (z.B. für Filenamen). Oder wenn du willst dass das Programm noch auf Win9x/ME läuft.
-
Wieso sollte es ein Problem mit Windows 95/98/ME geben, wenn ich wstring verwende? Selbst dieses alte Visual Studio 6.0 kannte schon den wstring, obwohl es für Windows 98 augelegt war ("Designed for Windows 98").
-
Klar kannst du auch wstring verwenden, aber dann mußt du darauf achten, IMMER die wchar_t-Version einer API-Funktion aufzurufen (und inwieweit ältere Systeme eine wchar_t-Version deiner Funktionen unterstützen, ist die andere Frage).
-
Aha, ja, natürlich "geht" std::wstring mit Windows 95/98/ME, aber die ganzen Unicode APIs gehen nicht.
Was willst du also mit deinen wstrings anfangen wenn du sie in keine einzige API reinstecken kannst?
-
O.k., ich glaube, ich hab's jetzt verstanden. Danke an alle.
Noch eine Frage: Wie kann man diesen wstring eigentlich ausgeben? cout funktioniert damit nicht.
-
Ach ja, und noch etwas: Was hat es eigentlich mit dieser Funktion tmain oder _tmain auf sich?
-
Turk Turkleton schrieb:
Noch eine Frage: Wie kann man diesen wstring eigentlich ausgeben? cout funktioniert damit nicht.
Es gibt auch wchar_t Versionen der IO-Streams - die fangen bezeichnenderweise mit "w" an, wie z.B. "wcout" (das brauchst du).
Ach ja, und noch etwas: Was hat es eigentlich mit dieser Funktion tmain oder _tmain auf sich?
Das kann je nach Compiler-Optionen als main() (für char-Daten) oder wmain() (für wchar_t) erstellt werden.
-
Es gibt auch wchar_t Versionen der IO-Streams - die fangen bezeichnenderweise mit "w" an, wie z.B. "wcout" (das brauchst du).
Der Compiler kennt aber kein wcout, zumindest nicht in der iostream.
Das kann je nach Compiler-Optionen als main() (für char-Daten) oder wmain() (für wchar_t) erstellt werden.
Das versteh ich mal wieder nicht. Was hat denn der Name der main mit char- oder wchat_t-Daten zu tun?
-
Turk Turkleton schrieb:
Wieso haben die das nicht gleich von vornherein in den Standard-String reingenommen?
Weil es in C++ keine explizite Differenzierung zwischen ASCII und UNICODE gibt.
Turk Turkleton schrieb:
Der Compiler kennt aber kein wcout, zumindest nicht in der iostream.
Doch eigentlich schon (ist im std-Namensbereich definiert):
// In der Datei IOSTREAM: extern _CRTIMP wostream wcout, wcerr, wclog;Turk Turkleton schrieb:
Das versteh ich mal wieder nicht. Was hat denn der Name der main mit char- oder wchat_t-Daten zu tun?
Guck Dir mal die erweiterte Version der main() mit Parametern an... . Dann siehst du warum man zwischen char und wchar_t unterscheidet.
-
Komisch: Unter Linux mit dem GCC geht's. Unter Windows mit dem MinGW geht's nicht ('wcout' undeclared (first use this function)).
-
Weiß einer, warum das so ist. Ich dachte, der MinGW wäre standardkonform.
-
Soll ich Dich ins "Compiler-Forum" verschieben!? Aber nach dem Titel zu urteilen, wäre esinnvoller, Du würdest diese Frage dort nochmal neu stellen...
-
Turk Turkleton schrieb:
Weiß einer, warum das so ist. Ich dachte, der MinGW wäre standardkonform.
guckst du: http://www.mingw.org/MinGWiki/index.php/wide characters
