Kompatibilität von LPCTSTR und std::string

Oh, vielen Dank.
Wenn ich das richtig sehe, müsste man dann ja, wenn man wiederverwertbare Klassen schreibt, immer einen eigenen String definieren und das Makro TEXT benutzen, da man ja nie weiß, ob der Benutzer der Klasse nicht UNICODE definiert hat, stimmt's?

Das letzte war übrigens eine Frage.

CodeFinder

Turk Turkleton schrieb:

Oh, vielen Dank.
Wenn ich das richtig sehe, müsste man dann ja, wenn man wiederverwertbare Klassen schreibt, immer einen eigenen String definieren

Hä, das musst du noch mal erläutern, hab keine Ahnung, was du damit meinst .

Turk Turkleton schrieb:

und das Makro TEXT benutzen, da man ja nie weiß, ob der Benutzer der Klasse nicht UNICODE definiert hat, stimmt's?

Jo das ist korrekt .

CodeFinder

Turk Turkleton schrieb:

Das letzte war übrigens eine Frage.

Immer mit der Ruhe...

Hä, das musst du noch mal erläutern, hab keine Ahnung, was du damit meinst

Damit meinte ich: Wenn ich eine Klasse schreibe und diese nimmt Strings als Parameter für irgendwelche Methoden entgegen, dann muss ich doch immer selbst einen String definieren und kann nicht einfach std::string nehmen, da ich ja nie weiß, ob der Programmierer, der meine Klasse benutzt, nun Unicode definiert hat oder nicht. Das heißt, ich müsste jedesmal das machen, was Du am Anfang gesagt hast:

#if (defined (UNICODE)) || (defined (_UNICODE))
    typedef std::wstring  STRING;
#else
    typedef std::string   STRING;
#endif

Ich kann also nicht einfach einen vorhandenen String-Typ nehmen und mich darauf verlassen, dass der immer korrekt ist. Liege ich damit richtig?

CodeFinder

Jo damit liegt du richtig...es sei denn du weißt das deine Klasse niemals/nur mit UNICODE benutzt wird.

Du kannst dich aber auch damit absichern:

#if (defined (UNICODE)) || (defined (_UNICODE))
  #error "Klasse CIrgendwas unterstützt kein UNICODE. Kompilierung wurde abgebrochen!"
#endif

Oder sowas ...

Wieso haben die das nicht gleich von vornherein in den Standard-String reingenommen? So dass der entsprechend definiert wird, je nachdem, ob Unicode definiert ist oder nicht?
Was passiert eigentlich, wenn ich wstring verwende, ohne dass Unicode definiert ist? Wäre ich damit nicht auf jeden Fall auf der sicheren Seite, auch was mein ursprüngliches Problem (LPCTSTR) betrifft?

hustbaer

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?

hustbaer

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").

CStoll

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).

hustbaer

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?

CStoll

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?

CodeFinder

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.

main(...)/wmain(...) (MSDN, C++ Reference)

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.