C/C++ Forum :: VisialStudio: MultiByte vs Unicode

xor Mitglied 20:03:15 02.09.2010 Titel:

Also die technische Erklärung ist einfach: std::string ist ein std::basic_string<char> und std::wstring ist ein std::basic_string<wchar_t>. Und damit kann ein std::string nur mit char umgehen während ein std::wstring nur mit wchar_t umgehen kann

Ich mache daher meist folgendes

C/C++ Code:
#if defined(UNICODE) \|\| defined(_UNICODE) # define tstring wstring #else # define tstring string #endif

C/C++ Code:
#if defined(UNICODE) \|\| defined(_UNICODE) # define tstring wstring #else # define tstring string #endif

C/C++ Code:
#if defined(UNICODE) \|\| defined(_UNICODE) # define tstring wstring #else # define tstring string #endif

Im Projekt benutze ich dann immer den "tstring" und das _T - Makro.

PS: Man kann sich aber auch eine eigene String-Klasse schreiben, wo die Methoden entsprechend überladen sind und dann MultiByteToWideChar / WideCharToMultiByte einsetzen

Der_Knob Mitglied 22:53:32 02.09.2010 Titel:

mh, ne eigene Klasse klingt jetzt aber auch nicht gerade reizvoll
Also muss ich überall die Makros verwenden?

Was für eins ist da jetzt besser? L oder _T?

Dravere Moderator 23:49:42 02.09.2010 Titel:

Der_Knob schrieb:

Was für eins ist da jetzt besser? L oder _T?

L ist kein Makro, sondern ein Sprachteil von Standard C++. L sagt dem Kompiler, dass das Stringliteral ein Widestring darstellen soll. Also in Code:

C/C++ Code:
char const* c = "hello"; // ist ein char[6] wchar_t const* w = L"hello"; // ist ein wchar_t[6]

C/C++ Code:
char const* c = "hello"; // ist ein char[6] wchar_t const* w = L"hello"; // ist ein wchar_t[6]

C/C++ Code:
char const* c = "hello"; // ist ein char[6] wchar_t const* w = L"hello"; // ist ein wchar_t[6]

_T ist ein Kompilerabhängiges Makro und nicht Teil von Standard C++. Das Makro _T ist unter MSVC ca. wie folgt definiert:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	1 2 3 4 5 6 7 8 9 10 11 12	#if defined(UNICODE) # define _T(x) L ## x #else # define _T(X) x #endif // Wenn UNICODE gesetzt ist, expandiert folgender Ausdruck: _T("hello") // zu L"hello" // Falls UNICODE nicht gesetzt ist, dann wird daraus: "hello"

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	#if defined(UNICODE) # define _T(x) L ## x #else # define _T(X) x #endif // Wenn UNICODE gesetzt ist, expandiert folgender Ausdruck: _T("hello") // zu L"hello" // Falls UNICODE nicht gesetzt ist, dann wird daraus: "hello"

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	#if defined(UNICODE) # define _T(x) L ## x #else # define _T(X) x #endif // Wenn UNICODE gesetzt ist, expandiert folgender Ausdruck: _T("hello") // zu L"hello" // Falls UNICODE nicht gesetzt ist, dann wird daraus: "hello"

Wenn du sowieso kein Multibyte verwenden willst und nur Unicode, wozu ich eigentlich auch raten würde, dann verwende immer gleich L, wchar_t und std::wstring. Die Makros kannst du dir sparen.

Jochen Kalmbach schrieb:

Das frage ich mich auch schon immer...

Ich hoffe, dass dies nicht dein Ernst ist? Ansonsten:
http://www.gotw.ca/gotw/019.htm

Grüssli

Unregistrierter

Aber warum nicht auf Multibyte stellen?
Man verwendet normal ASCII Strings und wo man Unicode braucht, nimmt man es halt.

Microsoft MVP VC++ · Jochen Kalmbach Moderator 12:22:37 03.09.2010 Titel:

Hä? Wie soll denn das gehen? Das ist ja dann ein furchbares durcheinander was kaum durchgängig funktionieren wird...

Unregistrierter

Wenn man auf Unicode stellt, kann man doch gar keine ASCII-Stringliterale mehr definieren?!
In einigen Anwendungen braucht man aber sowohl ASCII/ANSI (whatever lol) und Unicode. Dann stellt man halt auf Multibyte und wo man char* braucht, definiert man char* = "", und wo man wchar_t* braucht, definiert man halt wchar_t* = L""...
Nicht?

Dravere Moderator 13:24:55 03.09.2010 Titel:

Hi schrieb:

Wenn man auf Unicode stellt, kann man doch gar keine ASCII-Stringliterale mehr definieren?!

Wie kommst du auf den Unsinn? Grundsätzlich wird nur das Makro UNICODE gesetzt. Wodurch die WinAPI Funktionen zur W-Funktion expandieren. Also zum Beispiel aus MessageBox wird dann MessageBoxW. Es hindert dich aber niemand daran direkt MessageBoxA aufzurufen.

Hi schrieb:

In einigen Anwendungen braucht man aber sowohl ASCII/ANSI (whatever lol) und Unicode. Dann stellt man halt auf Multibyte und wo man char* braucht, definiert man char* = "", und wo man wchar_t* braucht, definiert man halt wchar_t* = L""...

Wenn du auf Unicode stellst, kannst du dies genau gleich verwenden. Daran ändert die Einstellung nichts.

Grüssli

rüdiger Moderator 14:24:45 03.09.2010 Titel:

xor schrieb:

Für das Speichern von Daten hat sich UTF8 für mich bewährt, eben weil man es unter Linux stillschweigend für System-Aufrufe nutzen kann. Unter Windows ist das allerdings eine ungute Herumkonvertiererei. Der einzige Verteil ist, das UTF-8 in ein reguläres char-Array passt und so wunderbar system-unabhängig in Dateien geschrieben werden kann. Wenn man unter Windows Unicode benutzt verwendet man immer UTF-16, da der wchar_t 16 bit breit ist, während wchar_t unter vielen Unices 32 bit breit ist und UTF-32 darstellt.

UTF-8 und UTF-16 sind ja sogar VariableByte

.

IMHO sind UTF-8 und UTF-32 die einzig sinnvollen Unicodevarianten. Der Rest ist nur für Spezialfälle und Legacysysteme. UTF-8 ist gut, wenn man den Text möglichst klein haben will oder eben für Legacysysteme

. UTF-32 ist gut, wenn man sehr viel zeichenweise machen will.

Microsoft MVP VC++ · Jochen Kalmbach Moderator 15:29:04 03.09.2010 Titel:

UTF-16 ist gut, wenn man WinAPI Funktionen direkt ansprechen will... das geht nun mal mit UTF-8 nicht da Windows dies nicht als Encoding seiner *A-Funkionen nicht unterstützt.
Fazit: Verwende möglichst immer die *W-Funktionen, wenn Du alle Zeichensätze darstellen willst... und damit verwende auch "wchar_t" bzw. "UTF-16".

UTF-32 wird in der Praxis nie eingesetzt...

Dravere Moderator 17:32:54 03.09.2010 Titel:

rüdiger schrieb:

UTF-8 ist gut, wenn man den Text möglichst klein haben will oder eben für Legacysysteme

.

Nicht zum Beispiel im asiatischen Raum. Wenn ich mich recht erinnere brauchen gerade chinesische Zeichen in UTF-8 meistens 3 Bytes, während sie in UTF-16 nur 2 Bytes benötigten. Daher wird UTF-16 noch oft im asiatischen Raum eingesetzt.

rüdiger schrieb:

UTF-32 ist gut, wenn man sehr viel zeichenweise machen will.

Kannst du auch bei UTF-32 vergessen. Gewisse Zeichen setzen sich aus mehreren UTF-32 Werten zusammen. Man braucht genauso Indextabellen wie in UTF-8 und UTF-16.

Ein Vorteil von UTF-8 ist, dass man keine Unterscheidung zwischen LE und BE hat.

Grüssli