WideString steht nicht für Sonderzeichen.

Nicht-ASCII-Zeichen in einem normalen String sind erstmal völlig legal. Es hängt halt komplett von deiner Kodierung ab. Du kannst auch UTF-8 in einem normalen String speichern.

"aö"
im deutschen ASCII-code 3 chars ('a', 'ö', '\0')
in anderen ASCII-codes 3 chars ('a', '?', '\0')

In einem normalen String kann man den für sein Land spezifischen ASCII-Code packen...
bis 2^7 ist das weltweit(?) kompatibel - ab dann musst du (ziemlich aufwendig) umwandeln...

wenn dein programm also auf einem russischen os läuft, dann wird das mit ä,ö,ü,ß,... nichts mehr - dann musst du auf wchar_t setzen, also std::wstring...

falls du mehr wissen willst:
nach "UCS" bzw "UTF" googlen (bzw direkt bei wikipedia suchen)
oder du suchst hier im forum - ist auch eine immer wiederkehrende frage bzw problem ^^

bb

unskiled schrieb:

wenn dein programm also auf einem russischen os läuft, dann wird das mit ä,ö,ü,ß,... nichts mehr - dann musst du auf wchar_t setzen, also std::wstring...

Eben nicht. Es ist ein Trugschluss, dass std::wstring respektive wchar_t Ecnoding-Probleme löst. UTF-8 kann und sollte man eher in einem normalen Character-Array bzw. std::string ablegen. C++ kennt weder irgendwelche Formen von Encoding noch Unicode direkt, auch wenn man es den Streams beibringen kann. Vor der Ausgabe muss man das Encoding auf das des Ausgabemediums anpassen.
Und wenn auf einem russischen OS ein Character-Literal mit L"aö" kompiliert wird, kommt vermutlich auch nur Mist bei raus.

Eben nicht. Es ist ein Trugschluss, dass std::wstring respektive wchar_t Ecnoding-Probleme löst. UTF-8 kann und sollte man eher in einem normalen Character-Array bzw. std::string ablegen.

Quelle?

7H3 N4C3R schrieb:

C++ kennt weder irgendwelche Formen von Encoding noch Unicode direkt

C++ kennt std::wstring! Und hier in dem Thread gings nicht um Encoding...

7H3 N4C3R schrieb:

auch wenn man es den Streams beibringen kann. Vor der Ausgabe muss man das Encoding auf das des Ausgabemediums anpassen.

Jopp - ich habe auch nie behauptet, dass beispielsweise die windows-console alles ausgeben könnte, was windows auch verarbeiten kann...

7H3 N4C3R schrieb:

Und wenn auf einem russischen OS ein Character-Literal mit L"aö" kompiliert wird, kommt vermutlich auch nur Mist bei raus.

Deshalb sollte er mal nach UCS googlen - damit er merkt, dass man nicht L"äö" schreibt sondern die Unicode-Codierung nutzen sollte... (U+....)

und wenn ich hier so was wie

da ö nicht zum Standard C++ Character Set gehört

lese... naja, lassen wir das...

hf

Grüssli

wchar_t garantiert kein Unicode! [...] Welches Zeichen nun zu welchem Wert gehört, bestimmt auch bei wchar_t das aktuelle Locale.

quelle?
wchar_t garantiert mir, dass ich einem bestimmten zahlenwert genau einen buchstaben zuordnen kann - nämlich den, den der unicode-standard vorschreibt... dieser standard ist aber wiederrum international... das heißt aber, dass hier ein U+00AE genau das selbe darstellt, wie auch in Timbuktu?!
oder ist daran irgendwas falsch?

bb

und wenn ich hier so was wie

da ö nicht zum Standard C++ Character Set gehört

lese... naja, lassen wir das...

Aha, und was ist damit?

unskilled schrieb:

wchar_t garantiert mir, dass ich einem bestimmten zahlenwert genau einen buchstaben zuordnen kann - nämlich den, den der unicode-standard vorschreibt... dieser standard ist aber wiederrum international... das heißt aber, dass hier ein U+00AE genau das selbe darstellt, wie auch in Timbuktu?!
oder ist daran irgendwas falsch?

Quelle? (diese Zeile kann Spuren von Nüssen und Sarkasmus enthalten)

Du kannst auch wchar_t jeden anderen Zahlenwert zuordnen, auch einen den der Unicode-Standard nicht vorschreibt. Und das sogar, obwohl letzterer international ist.

Es ist wchar_t völlig egal, sowie C++ als solches auch, ob du darin Unicode ablegst oder eine Schweineborstenverwaltung damit umsetzt. Zumal es grob so um die 90000 zugeordnete Unicode-Characters gibt, da reicht ein wchar_t mit 2 Byte ja garnicht aus. Huch. Da braucht man ja plötzlich 2 von für einen Unicode-Character.
Wenn du ein U+wxyz irgendwo ablegst, hast du es schon in höchstem Maße mit Encoding zu tun. Einmal hast du dich auf Unicode festgelegt, zum anderen wählst du z.B. UTF-8, UTF-16LE, UTF-16BE oder vielleicht UTF-32 als Kodierung aus, abhängig vom Datentyp der die Daten aufnimmt. Und für einen Unicodecharacter braucht man u.U. mehrere "Characters" des zugrundeliegenden Typ. Für ein Glyph braucht man u.U. nochmal mehr. wchar_t brauchst du im Zusammenhang mit Unicode nur, wenn du dich für eine Kodierung entscheidest, die Unicodecharacters in 2-Byte oder meinetwegen 4-Byte breiten "Characters" der zugrundeliegenden Repräsentation kodiert.

Im übrigen siehst du auch in Timbuktu mit "\xC2\xAE" (ohne L) ein , wenn man's in UTF-8 kodiert.

Vielleicht interessiert dich auch das hier (eine Quelle...):

ISO 14882 schrieb:

2.13.2/5:

A universal-character-name is translated to the encoding, in the execution character set, of the character named. If there is no such encoding, the universal-character-name is translated to an implementation defined encoding. [Note: in translation phase 1, a universal-character-name is introduced whenever an actual extended character is encountered in the source text. Therefore, all extended characters are described in terms of universal-character-names. However, the actual compiler implementation may use its own native character set, so long as the same results are obtained.

Es wäre somit deine Aufgabe uns die Stelle im Standard zu zeigen, wo steht, dass wchar_t für Unicode zu verwenden sei.

Grüssli

Type wchar_t is a distinct type whose values can represent distinct codes for all members of the largest
extended character set specified among the supported locales (22.1.1). Type wchar_t shall have the same
size, signedness, and alignment requirements (3.9) as one of the other integral types, called its underlying
type

Nichts mit Unicode...