int MyMessageBox(std::string text, std::string caption, UINT type)
{
	return MessageBox(NULL, text.c_str(), caption.c_str(), type);
}

Über Sinn und Unsinn könnte man jetzt streiten, aber ist das so erstmal korrekt oder müsste ich die Strings erst noch irgendwie umwandeln, bevor ich sie an MessageBox übergebe?

typedef basic_string<TCHAR, char_traits<TCHAR>, allocator<TCHAR>> _tstring;

CodeFinder schrieb:

Oder du differenzierst selbst zwischen std::string und std::wstring ...

Verzeih die blöde Frage, aber was bedeutet zwischen std::string und std::wstring zu differenzieren?

Naja sowas:

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

EDIT: Entspricht aber summa sumarum Jochen's Vorschlag .

O.k., ich habe mich jetzt für erstere Variante entschieden. Doch nun gibt es noch ein Problem. Wenn ich folgenden Code schreibe:

#include <string>
#include <windows.h>

using namespace std;

typedef basic_string<TCHAR, char_traits<TCHAR>, allocator<TCHAR> > STRING;

int MyMessageBox(STRING text, STRING caption, UINT type);

int main ()
{
	MyMessageBox("Hallo", "Titel", MB_OK);

	STRING text="Text";
	STRING caption;

	caption="Caption";

	MyMessageBox(text, caption, MB_OK);

	return 0;
}

int MyMessageBox(STRING text, STRING caption, UINT type)
{
	return MessageBox(NULL, text.c_str(), caption.c_str(), type);
}

funktioniert alles. Wenn ich aber ganz oben ein

#define UNICODE

schreibe, funktioniert es nicht mehr, wenn ich versuche, einen festen String (variable="Wert") zu übergeben. Der Compiler meldet Konvertierungsfehler in Zeile 12, 14 und 17, das heißt, er kennt nun plötzlich keinen Konstruktor und keinen =-Operator mehr, der einen char[] übernimmt.

Wenn ich aber ganz oben ein

#define UNICODE

schreibe, funktioniert es nicht mehr, wenn ich versuche, einen festen String (variable="Wert") zu übergeben. Der Compiler meldet Konvertierungsfehler in Zeile 12, 14 und 17, das heißt, er kennt nun plötzlich keinen Konstruktor und keinen =-Operator mehr, der einen char[] übernimmt.

Nimm das Makro

TEXT("Ein String")

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 .

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?

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

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.

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?

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)