Also, ich fass das mal schnell zusammen:
Der Unicodestandard wurde entworfen um ein größeres Spektrum an Schriftzeichen am Computer verarbeiten zu können, und zwar mit einer einheitlichen Indizierung für jeden Glyphen. (Ohne z.B. Codepages austauschen zu müssen).
Es hat also mitnichten nur etwas mit "Sonderzeichen" zu tun, sondern wird, mittlerweilen, algemein zur Verarbeitung und Darstellung von Zeichen verwendet.
In vergangenen Zeiten gab es immer wieder Ansätze das Zeichenspektrum zu erweitern (selbst die englischsprachigen Länder mussten irgendwann zugeben das die 127 Zeichen des ASCII zu wenig waren). Darunter war z.B. ein erweiterter ASCII Zeichensatz, diverse Ansätze mit austauschbaren Codepages uswusf. Seit Windows 98SE unterstüzt Windows aber (immer mehr) auch Unicode.
Um rückwärtskompatibel zu bleiben bietet die Windows API (kurz WinAPI) für viele Funktionen zwei Typen an. Einmal den alten Typ für ANSI und einmal den neuen, der Unicode verwendet.
Die Namen der Funktionen enden, je nach Typ, mit einem A (Ansi) oder einen W (Widechar).
Zum Beispiel ist die Funktion MessageBoxW der Unicodeequivalent zur Funktion MessageBoxA. Um dies zu vereinheitlichen wurden Makros eingeführt hinter denen sich, je nach eingestellungen, entweder die Ansi oder die Unicodevariante der jeweiligen Funtkionen steckt.
Zum Beispiel:
#if defined( _UNICODE ) // Wenn Unicode verwendet wird
#define MessageBox MessageBoxW
#else // ansonsten
#define MessageBox MessageBoxA
#endif
Wenn man also die Funktion
MessageBox im Code verwendet, macht der Präprozessor entsprechend ein MessageBoxW oder MessageBoxA daraus.
Nun werden Unicodezeichen etwas anders im speicher repräsentiert als Ansizeichen. Für Ansi reichte die "Bandbreite" von 8 Bit aus (bei Windows entspricht das einem Byte = char). Unicode bietet aber mehr Platz für mehr Zeichen, deshalb benötigt ein Unicodezeichen 32 Bit (= 4 Byte). Um die Platzverschwendung möglichst gering zu halten (nicht alle Zeichen nutzen schließlich die 32 Bit eines Unicodecharakters) wurden diverse Techniken entwickelt die den Speicherverbrauch senken (UTF-8, UTF-16). Windows nutzt letzteres Codierungsverfahren und benötigt deshalb für einen Codepoint (=ein Unicodezeichen) mindestens 16 Bit.
Aus diesem Grund musste ein anderer Datentyp her um Zeichenketten zu repräsentieren, nämlich
wchar_t. Dieser Typ bietet under Windows32 genau die 16 Bit die benötigt werden und dieser Datentyp wird von den Unicodevarianten der WindowsAPI Funktionen erwartet.
Nun erwartet auch MessageBoxW den Typ wchar_t für die Textparameter. Deshalb kann der Code mit der übergabe von const char* auch nicht compiliert werden, weil der übergebene Typ schlichtweg falsch ist.
Anmerkung: LPCWSTR ist eine WinAPI eigene Definition für const wchar_t* (
Long
Pointer
Const
Wide
STRing).
Was tun sprach also Gates... (rein bildlich gesehen). Und es wurde eine weitere Definition eingeführt, die sich, abhängig vom verwendeten Zeichensatz, dynamisch anpasst:
#if defined( _UNICODE )
#define TCHAR wchar_t
#else
#define TCHAR char
#endif
Verwendet man also TCHAR (statt char oder wchar_t) so hat man immer den richtigen Datentyp für Zeichen bei der Hand!
grüße