Hi,

es gibt ja von vielen WinAPI befehlen einmal die A und die W variante, A für ANSI Strings und W eben für Unicode.

Früher habe ich einfach entweder die A-Funktion genommen, oder wenn es W sein mußte meinen char* String mit diversen funktionen konvertiert..

Jetzt habe ich allerdings meine String-Klasse welche intern mit UTF-8, UTF-16 und UTF-32 arbeiten kann. Und als ich eben gesehen habe das ich - aus faulheit damals - bei CreateWindowExW immernoch das ganze via konvertiern mache (Ich wandele meinen UTF-8 String in char* um, nur um ihn dann wieder in Unicode zu konverteren ) kam ich auf die idee: Wieso gebe ich nicht direkt meinen Unicode String weiter?

Problem hierbei ist, wie genau müßen die daten im speicher dafür aussehen? Windows arbeitet da ja mit UTF-32 soweit ich weiß, sprich pro zeichen einen 32bit Integer wert.. aber wie schaut es aus mit der länge des Strings? Ist das immernoch so wie bei ANSI Strings, sprich eine 0x0 an's ende?

Oder ist wchar_t intern doch irgendwie ganz anders definiert?

Hilfe..

Aya~

Deine Annahmen stimmen nicht so ganz.

W steht für Wide-Char und wchar_t ist intern (bzw. per typedef) als short (d.h. 16 bit bzw. 2 Byte) definiert.
Aber das Ende eines Strings ist dabei immer noch gleich, d.h. null-terminiert (nur bei Wide-Chars eben zwei Bytes).

Wenn du jedoch UTF-8 Strings hast, so kannst du diese nicht direkt übergeben, sondern mußt sie entsprechend umwandeln. Dafür gibt es verschiedene Libraries, z.B. utfcpp.sourceforge.net/

Hi,

Th69 hat folgendes geschrieben :

W steht für Wide-Char und wchar_t ist intern (bzw. per typedef) als short (d.h. 16 bit bzw. 2 Byte) definiert. Aber das Ende eines Strings ist dabei immer noch gleich, d.h. null-terminiert (nur bei Wide-Chars eben zwei Bytes).

Okay, danke. Das war genau was ich wissen wollte

Aya

Mhh... ich hab jetzt meinen UTF-16 String der am ende mit 0 terminiert ist an CreateWindowExW als Caption übergeben, aber die zeichen in der Caption vom Fenster was erstellt wird sind bei weitem nicht das was sie sein sollten.. (Es sollte eigentlich "Das ist ein Test" dastehen, stattdessen sind 3 kryptische zeichen da...)

Der UTF-16 String ist aufjedenfall 100% korrekt encoded... was könnte denn da das problem sein? :/

EDIT: Ah ne schon gut, war mein fehler

Aya hat folgendes geschrieben :

EDIT: Ah ne schon gut, war mein fehler

Wär schön zu wissen, was der Fehler war, damit auch andere daraus lernen können

Edit: Oh, C++, schade, ich hatte Delphi erwartet - dann wär ich am Ergebnis nämlich wesentlich interessierter gewesen

JayEff hat folgendes geschrieben :

Aya hat folgendes geschrieben : EDIT: Ah ne schon gut, war mein fehler Wär schön zu wissen, was der Fehler war, damit auch andere daraus lernen können Edit: Oh, C++, schade, ich hatte Delphi erwartet - dann wär ich am Ergebnis nämlich wesentlich interessierter gewesen

War im endeffekt nur ein dämlicher pointer fehler den ich gemacht hab
Ich hatte als einen Pointer auf meine UTF16String Klasse übergeben und vergessen in dieser den &-Operator zu überschreiben.. dadurch kam bei CreateWindowExW halt ein Poiner auf meine klasse an statt auf den UTF16-String selbst ^^

Aya~

PS: Was genau hätte dich denn daran interessiert? Evtl kann ich trotzdem helfen

Aya hat folgendes geschrieben :

PS: Was genau hätte dich denn daran interessiert? Evtl kann ich trotzdem helfen

Ach nichts, ich find nur Ergebnisse lustig, die zu funktionieren scheinen, bis man merkt, dass die Ausgabe nur kryptisch ist

Hrm, zufrüh gefreut...

Wenn ich ihm jetzt den String "Das ist ein Test" als UTF-16 codiert gebe, steht in der Caption nur "D".. wenn ich mir die einzelnen short-ints ausgeben lasse ist aber alles richtig, also die 0 ist erst am ende vom Satz..

Woran kann denn das liegen?

Am Pointer liegt es aufjedenfall nichtmehr..

Wenn in der Caption nur ein D steht, dann wird höchstwahrscheinlich irgendwo in der Kette der Aufrufe das als PChar (oder wie das bei c++ sonst heißt, eben als Ansi-String) interpretiert. Denn das zweite Byte von dem zwei-Byte-Zeichen "D" ist ein Nullbyte, was bei einem PChar das Terminierungssymbol ist.

Gausi hat folgendes geschrieben :

Wenn in der Caption nur ein D steht, dann wird höchstwahrscheinlich irgendwo in der Kette der Aufrufe das als PChar interpretiert. Denn das zweite Byte von dem zwei-Byte-Zeichen "D" ist ein Nullbyte, was bei einem PChar das Terminierungssymbol ist.

Mh stimmt, das wäre plausibel.. aber wo? :/

Das kann ich dir ohne Code auch nicht sagen.

Irgendwo wird wohl noch eine Ansi-Api-Funktion aufgerufen, d.h. es fehlt einfach irgendwo ein "W".

Klappt jetzt, ich mußte in den compiler-optionen erst noch UNICODE Support aktivieren..

Allerdings hab ich jetzt noch ein anderes problem.. wie kann ich denn file-streams (ifstream, ofstream) mit Unicode zeichen verwenden? Unter Windows gibt es dafür wohl sowas wie wofstream und wifstream, allerdings brauche ich es Platformunabhängig..

Aya~

wifstream und wofstream sind nur typedefs, d.h. diese funktionieren auch unter Linux etc: