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

Der_Knob Mitglied 14:55:03 28.08.2010 Titel:

Ich wollte mal ein paar Fragen zu MultiByte vs Unicode Einstellung bei VisualStudio Projekten stellen.

Wie wichtig ist die Umstellung von MultiByte auf Unicode? Wird MultiByte irgendwann nicht mehr unterstützt werden?

Was für Vorteile bringt mir die Umstellung?

Was hat das für Performance Einflüsse hat die Umstellung?

Danke schon mal!

xor Mitglied 23:54:17 28.08.2010 Titel:

Vereinfacht gesagt macht Multibyte ab Studio 2008 keinen Sinn mehr.
Die 9x-Windows-Reihe unterstützte nur ANSI (Multibyte) in der WinAPI, dort gab es es kein Unicode (außer man hatte den Unicode-Layer nachinstalliert).
Windows NT+ implementiert beide APIs, wobei intern mit Unicode gearbeitet wird und die ANSI APIs hin- und her-konvertieren mussten... das sollte auch bei Windows 7 weiter so sein.

Nachdem aber mit dem Studio 2008 der Support für NT4 und Win9x eingestellt wurde und die EXEen von diesen System auch gar nicht mehr erkannt werden, macht es keinen Sinn mit Studio 2008 ein Multibyte Programm zu erzeugen. Es würde zwar auf den neueren Versionen von Windows laufen, aber ist performance-technisch gesehen eher ein Nachteil. Letztes Studio für alte Windows Versionen mit Nur-Multibyte ist also 2005.

Wer aber mit TCHARs arbeitet, kann leicht zwischen Unicode und Multibyte umschalten

Ob die ANSI-Versionen der WinAPI irgend wann einmal nicht mehr unterstützt sind ist schwer zu sagen. So lange eine größere Anzahl an Programmen die eine oder andere API nutzt, kann MS es sich eigentlich nicht leisten die Kompatibilität zu brechen. Sogar in Windows Vista und 7 neu eingeführte APIs sind immer nocht doppelt implementiert (ANSI und Unicode) ...
Bedenkt man aber, dass der Support für 16-bit Programme nun auch eingestellt ist, kann es durchaus passieren, dass das übernächste Windows keine ANSI - APIs mehr hat :eek:

(da würden einige DLLs kleiner werden

)

Ein Vorteil von Unicode ist natürlich die korrekte Speicherung und Darstellung von allen weltweit genutzten Codes. Mir ist da eine dumme Backup-Software bekannt, die beim Sichern und Wiederherstellen einiger russischer bzw. japanischer Dateien kaputte Dateinamen generierte ... worauf dann Links nicht mehr funktionierten usw. Sowas ist für mich ein klassicher ANSI-Fehler (da haben meine Programme auch schon darunter gelitten :rolleyes:

)
Typischer Fehler ist: Deutsches Windows speichert ANSI-Dateinamen oder URL in eine Datei/Datenbank
Japanisches Windows liest ANSI-String und versucht die Ressource zu öffnen -> FileNotFound/404 ...

lg XOR

Der_Knob Mitglied 14:37:47 29.08.2010 Titel:

Danke für die ausführliche Antwort!

Das hat dann mal alle meine Fragen beantwortet :live:

Da ich mit VS 2008 entwickle werde ich dann auf Unicode umstellen

daersc Mitglied 13:31:06 31.08.2010 Titel:

Wie sieht das denn jetzt aus, wenn ich portierbare Programme für Windows und Linux schreiben will? Verwende ich jetzt auch einfach immer Unicode?

Unregistrierter

daersc schrieb:

Wie sieht das denn jetzt aus, wenn ich portierbare Programme für Windows und Linux schreiben will? Verwende ich jetzt auch einfach immer Unicode?

Wie willst du die WinAPI für Linux benutzen? :o)

daersc Mitglied 21:24:37 31.08.2010 Titel:

Ich dachte eher an ein übergreifendes Toolkit wie wxWidgets...

rüdiger Moderator 21:43:53 31.08.2010 Titel:

xor schrieb:

Die 9x-Windows-Reihe unterstützte nur ANSI (Multibyte) in der WinAPI, dort gab es es kein Unicode (außer man hatte den Unicode-Layer nachinstalliert).

ANSI encoding (korrekt eigentlich Windows 1252) ist doch kein Multibyteencoding. Das passt doch alles schön in ein Byte (256 Zeichen).

xor Mitglied 13:49:36 02.09.2010 Titel:

rüdiger schrieb:

xor schrieb:

Die 9x-Windows-Reihe unterstützte nur ANSI (Multibyte) in der WinAPI, dort gab es es kein Unicode (außer man hatte den Unicode-Layer nachinstalliert).

ANSI encoding (korrekt eigentlich Windows 1252) ist doch kein Multibyteencoding. Das passt doch alles schön in ein Byte (256 Zeichen).

Ja da hast du natürlich recht, wobei meines Wissens "ANSI" (bei API-Funktionen) für so ziemlich alles stehen kann, was aus einzelnen Bytes besteht. Die ANSI-Funktionen arbeiten dann (bitte korregiert mich, wenn ich irre

) unter einem chinesischen Windows mit einem chinesischen Multi-Byte (Double-Byte) String, während sie bei uns mit Windows-1252 (also Single-Byte) nutzen.

Für mich bedeutet daher ANSI unter Windows nur "irgend ein lokal-kodierter Byte-String". Aber das ist so nicht korrekt formuliert ... stimmt

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.

Wer unter Windows

C/C++ Code:
fwrite(L"Hello World", sizeof(wchar_t), 11, f);

C/C++ Code:
fwrite(L"Hello World", sizeof(wchar_t), 11, f);

C/C++ Code:
fwrite(L"Hello World", sizeof(wchar_t), 11, f);

schreibt, bekommt unter Linux mit

C/C++ Code:
wchar_t buffer[20] = { 0 }; fread(buffer, sizeof(wchar_t), 11, f);

C/C++ Code:
wchar_t buffer[20] = { 0 }; fread(buffer, sizeof(wchar_t), 11, f);

C/C++ Code:
wchar_t buffer[20] = { 0 }; fread(buffer, sizeof(wchar_t), 11, f);

Probleme

cu
XOR

Der_Knob Mitglied 18:05:40 02.09.2010 Titel:

mir stellt sich auch noch ein Frage

Warum kann man nicht mehr folgendes schreiben:

std::wstring dirINI;
dirINI = SallyAPI::System::SystemHelper::GetModulePath();
dirINI.append("option.ini");

Also die letzte Zeile... hiefür muss man ja jetzt

dirINI.append(L"option.ini");

oder

dirINI.append(_T("option.ini"));

schreiben... oder liegt das an Project/Compiler Einstellungen?

Microsoft MVP VC++ · Jochen Kalmbach Moderator 18:42:16 02.09.2010 Titel:

Was ist genau dier Frage?
Warum der wstring keine automatische Konvertierung von "const char*" hat?

Das frage ich mich auch schon immer...