Konventionen für Funktionsprototypen

Das Windows SDK stellt Funktionsprototypen in generischen Versionen, Windows-Codepages und Unicode-Versionen bereit. Die Prototypen können kompiliert werden, um entweder Windows-Codepage-Prototypen oder Unicode-Prototypen zu erstellen. Alle drei Prototypen werden in diesem Thema erläutert und durch Codebeispiele für die SetWindowText-Funktion veranschaulicht.

Im Folgenden finden Sie ein Beispiel eines generischen Prototyps:

BOOL SetWindowText(
  HWND hwnd,
  LPCTSTR lpText
);

Die Headerdatei enthält den generischen Funktionsnamen als Makro implementiert.

#ifdef UNICODE
#define SetWindowText SetWindowTextW
#else
#define SetWindowText SetWindowTextA
#endif // !UNICODE

Der Präprozessor erweitert das Makro entweder auf die Windows-Codepage oder den Namen der Unicode-Funktion. Der Buchstabe "A" (ANSI) oder "W" (Unicode) wird nach Bedarf am Ende des generischen Funktionsnamens hinzugefügt. Die Headerdatei stellt dann zwei spezifische Prototypen bereit, einen für Windows-Codepages und einen für Unicode, wie in den folgenden Beispielen gezeigt.

BOOL SetWindowTextA(
  HWND hwnd,
  LPCSTR lpText
);
BOOL SetWindowTextW(
  HWND hwnd,
  LPCWSTR lpText
);

Wie unter Windows-Datentypen für Zeichenfolgen erläutert, verwendet der Prototyp der generischen Funktion den Datentyp LPCTSTR für den Textparameter. Allerdings wird für den Windows-Codeseitenprototyp der Typ LPCSTR und für den Unicode-Prototyp der Typ LPCWSTR verwendet.

Für alle Funktionen mit Textargumenten sollten Anwendungen normalerweise die generischen Funktionsprototypen verwenden. Wenn eine Anwendung "UNICODE" entweder vor den #include-Anweisungen für die Headerdateien oder während der Kompilierung definiert, werden die -Anweisungen in Unicode-Funktionen kompiliert.

Hinweis

Neue Windows-Anwendungen sollten Unicode verwenden, um die Inkonsistenzen verschiedener Codepages zu vermeiden und die Lokalisierung zu vereinfachen. Sie sollten mit generischen Funktionen geschrieben werden und UNICODE definieren, um die Funktionen in Unicode-Funktionen zu kompilieren. An den wenigen Stellen, an denen eine Anwendung mit 8-Bit-Zeichendaten arbeiten muss, kann sie explizit die Funktionen für Windows-Codepages verwenden.

 

Die Anwendung sollte stets einen generischen Funktionsprototyp mit den generischen Typen für Zeichenfolgen und Zeichen verwenden. Alle Funktionen, die mit dem Großbuchstaben "W" enden, nehmen Unicode-Parameter entgegen, d. h. Breitzeichen. Einige Funktionen sind nur in Unicode-Versionen vorhanden und können nur mit den entsprechenden Datentypen verwendet werden. Beispielsweise verfügen LCIDToLocaleName und LocaleNameToLCID nur über Unicode-Versionen.

Der Abschnitt "Anforderungen" in der Referenzdokumentation für jede Unicode- und Zeichensatzfunktion enthält Informationen zu den Funktionsversionen, die von unterstützten Betriebssystemen implementiert werden. Wenn eine Zeile enthalten ist, die mit "Unicode" beginnt, verfügt die Funktion über separate Unicode- und Windows-Codepageversionen.

Hinweis

Wenn eine Funktion über einen Längenparameter für eine Zeichenfolge verfügt, sollte die Länge als Anzahl von TCHAR-Werten in der Zeichenfolge dokumentiert werden. Dieser Datentyp bezieht sich auf Bytes für Windows-Codepageversionen der Funktion oder 16-Bit-Wörter für Unicode-Versionen. Funktionen, die Zeiger auf nicht typisierte Speicherblöcke erfordern oder zurückgeben, wie z. B. die GlobalAlloc-Funktion , nehmen jedoch in der Regel eine Größe in Bytes an, unabhängig vom verwendeten Prototyp. Wenn die Zuordnung von nicht typisiertem Arbeitsspeicher für eine Zeichenfolge gilt, muss die Anwendung die Anzahl der Zeichen mit sizeof(TCHAR) multiplizieren. Weitere Informationen finden Sie unter Verwenden generischer Datentypen.

 

Unicode in der Windows-API