spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo,

Mir ist aufgefallen, das immer wieder Fragen gestellt werden, in denen Leute bei Fehlern im Zusammenhang mit Unicode nicht weiterkommen. Deshalb will ich hier kurz erläutern, wie man alle Fehler mit Unicode ganz einfach umgehen kann.

Zuerst will ich erwähnen, dass man Unicode beliebig in seinem Programm ein oder ausschalten kann. Das geht folgendermaßen:
Man geht auf Projekt/Eigenschaften/Konfigurationseigenschaften/Allgemein und wählt im Feld Zeichensatz entwerde Unicode oder Multi-Byte aus.

Man kann zwar alle Probleme mit Unicode aus der Welt schaffen, indem man Unicode einfach ausschaltet. Das das keine gute Lösung ist, kann man am besten anhand eines Beispiels erläutern:

Angenommen ihr wollt ein Programm schreiben. Dieses Programm soll zum einen in einer Sprache verfügbar sein, die die lateinischen Schriftzeichen verwendet (also Deutsch, Englisch, ...) und zum anderen in einer östlichen Sprache (z.B. Japanisch) die ein ganz anderes Alphabet von Schriftzeichen verwendet. Bei der Verwendung von Multi-Byte müsste man nun das Programm zweimal, nämlich unter einem Betriebssystem mit der einen und anschließend auf einem Betriebssystem mit der anderen Sprache kompilieren. Um dieses Problem zu umgehen verwendet man Unicode.

Außerdem beugt man viele Fehler vor, wenn man z.B. eine Engine so gestaltet, dass sie sowohl mit als auch ohne Unicode zurecht kommt.

Nun kommen wir zum ersten Problem.
Oft verzweifeln Leute an Fehlermeldungen à la

Zitat

MessageBoxW: Konventierung des zweiten Parameters von LPCSTR in LPCWSTR nicht möglich

Diese Fehlermeldung liegt daran, dass Unicode-Zeichen (auch als breite Zeichen bezeichnet) viel mehr Speicher belegen, wie Multi-Byte Zeichen. Deshalb gibt es für Unicode spezielle Datentypen. Da es aber ein besserer Stil ist, Datentypen einzusetzen, die je nachdem, ob Unicode eingestellt ist oder nicht für Unicode oder Multi-Byte-Zeichen stehen. Diesen Datentyp gibt es nur für einzelne Schriftzeichen aber nicht für Strings er lautet:


Für Unicode-Strings gibt es die Datentypen:
PCWSTR
LPCWSTR

bei Multi-Byte sind das:
PCSTR
LPCSTR

Unicode Strings haben noch eine Besonderheit. Vor ihnen muss immer ein L stehen. Das sieht dann so aus:

bzw.:


Folgender Code führt also bei eingestelltem Unicode zur obigen Fehlermeldung:


Wenn man nun ein L vor die Strings setzt, ist der Fehler behoben, aber wenn man nun Multi-Byte einstellt, kommt folgende Fehlermeldung:

Zitat

MessageBoxA: Konventierung des Parameters 2 von LPCWSTR in LPCSTR nicht möglich

An dieser Stelle möchte ich noch kurz erwähnen, wofür das W und das A stehen, wenn man doch nur MessageBox benutzt hat. Das liegt daran, das MessageBox je nachdem ob Unicode definiert ist oder nicht Als MessageBoxA(Multi-Byte Version) oder MessageBoxW(Unicode-Version) definiert ist.

Hier kommmt nun ein Makro ins Spiel, das in WinDef.h definiert ist. Da WinDef.h von windows.h eingebunden wird, muss man also keine weiteren Headerdateien einbinden. Das Makro setzt je nachdem, ob Unicode Definiert ist ein L vor den String oder nicht. Das Makro wird wie folgt verwendet:


Also muss man einfach immer, wenn eine Funktion eine Unicode und eine Multi-Byte Variante hat den Text über das Makro TEXT übergeben und schon ist man alle Probleme mit Unicode los und kann die Vorteile die der erweiterte Zeichensatz bietet in vollen Zügen ausnutzen.

Das Beispiel mit MessageBox würde dann wie folgt aussehen:


zugegeben, es ist Gewohnheitssache, aber es lohnt sich.

Zitat von »"Chase"«

Auf Multibyte kann man naemlich imo heutzutage verzichten!

Angenommen, du hättest eine Engine erstellt, die auch andere Leute außer dir benutzen. Dann benutzt die jemand, der Multi-Byte verwenden will, und wundert sich, weshalb er ~100 Fehlermeldungen bekommt. Es stimmt zwar, dass Multi-Byte für die Programmierung unter Windows mehr oder weniger unnötig ist, aber z.B. kann man in Konsolenanwendungen kein Unicode benutzen und ist auf Multi-Byte angewiesen.

Und aus genau diesem Grund habe ich nicht nur erklärt, wie man Unicode verwendet, sondern auch, wie man seinen Code allgemeingültig hält. So kann man von Fall zu Fall selbst entscheiden ob Unicode sinvoll ist oder nicht und kann trotzdem den gleichen Code verwenden, den man auch verwendet, wenn man Unicode benutzt.