TCHAR string
-
Ein string ist doch als Klassentemplate realisiert, oder? Müsste es da nicht auch strings geben, die auf TCHAR basieren? (Wegen der unterscheidung zw. UNICODE oder ASCII)
-
TChAR? kenn ich nicht, istd as standard c++?
sieht mir sehr nach borland aus->AnsiString
-
@ness
es gibt sowohl spezialisierungen für char und wchar_t, string ist eigentlich nur ein typedef für den Typ basic_string<char,char_traits<char>,allocator<char> > und der Unicode Typ für wchar_t eben entsprechen basic_string<wchar_t,char_traits<wchar_t>,allocator<wchar_t> > (wobei eigentlich basic_string<char> bzw. basic_string<wchar_t> reicht, da die anderen Argumente in dem Fall implizit sind). Du siehst also, dass es kein Problem ist std::basic_string<TCHAR> (wobei ich persönlich komplett Großschreibung ekelhaft finde) zu nehmen, was dann je nach dem zu einem der beiden Varianten evaluiert.Wobei du darauf achten musst, dass wenn wchar_t nicht UCS-4/UTF-32 entspricht (dh. 4Byte groß ist), musst du um voll Unicode zu unterstützen idr. UTF-16 (wenn wchar_t 2Byte groß ist) benutzen, dass ist aber ein Multibyte Zeichensatz und dafür ist basic_string _nicht_ ausgelegt!
Ist vielleicht ein wenig wirr, was ich geschrieben habe
@otze
AFAIK ist das ein WinAPI typedef oder wahrscheinlich sogar ein #define auf wchar_t, wenn man UNICODE definiert hat, ansonsten auf char.
-
Wobei du darauf achten musst, dass wenn wchar_t nicht UCS-4/UTF-32 entspricht (dh. 4Byte groß ist), musst du um voll Unicode zu unterstützen idr. UTF-16 (wenn wchar_t 2Byte groß ist) benutzen, dass ist aber ein Multibyte Zeichensatz und dafür ist basic_string _nicht_ ausgelegt!
ähäh, UTF-16 ist kein multibyte-Zeichensatz, falls du damit meinst, dass verschiedene Zeichen verschieden viel Speicher brauchen können. Jedes Zeichen wird mit der gleichen Anzahl an Bytes codiert (2).
Dieses seltsame Multibyte implementiert MS über den normalen char.
-
@kingruedi ich ließ mich vom T verleiten...
gleich mal ein paar C-Unser beten, damit mir der große Coder verzeiht
(ja, ich weis, C++-Unser wäre besser, aber das hört sich doch nicht an^^)
-
natürlich ist UTF-16 ein Multibyte Zeichensatz, wie willst du sonst 32Bit auf 16Bit abbilden? Ich zitiere
rfc2781 - UTF-16, an encoding of ISO 10646 schrieb:
In the UTF-16 encoding, characters are represented using either one or two unsigned 16-bit integers, depending on the character value.
-
Stimmt, ich wusste noch gar nicht, dass es auch in der UTF-16 Kodierung möglich ist, höherwertige Zeichen darzustellen. Das scheint jedoch nur in seltenen Fällen in ostasiatischen Sprachen nötig zu sein. Die benutzen dann auch gleich lieber UTF-32.
Deshalb hast du jetzt natürlich streng genommen trotzdem Recht, weil die Möglichkeit besteht.
-
@Optimizer
wie, die nehmen gleich UTF-32? Es geht doch darum, dass dein Programm Unicode kompatibel ist, das ist es aber nicht, wenn du damit nicht alle Zeichen abspeichern kannst, vorallem kannst du so sicher einige lustige effekte/Abstürze erzeugen. Ich weiss aber nicht in wie fern Windows UTF-16 unterstützt oder noch auf UCS-2 basiert.Fakt ist nur, für aktuelles Unicode braucht man 32Bit und wenn eine Anwendung Unicode kompatibel sein will, kann man da nicht mit UCS-2 oä. rumwurschteln.
(Persönlich finde ich UTF-16 übrigens nicht so toll, ist irgend wie ein dummer Kompromiss zwischen UTF-8 und UTF-32 :))
-
Die nehmen teilweise (ich weiß aber nicht, ob größtenteils) das UTF-32 Encoding, um dieses multibyte-System zu vermeiden. Die Nachteile sind ja hinlänglich bekannt.
Es geht doch darum, dass dein Programm Unicode kompatibel ist, das ist es aber nicht, wenn du damit nicht alle Zeichen abspeichern kannst
Mir ist gerade der Zusammenhang nicht klar. Für die allermeisten Texte reichen 16 Bit pro Zeichen aus und deshalb ist UTF-16 auch eigentlich die gebräuchlichste Codierung.
Fakt ist nur, für aktuelles Unicode braucht man 32Bit und wenn eine Anwendung Unicode kompatibel sein will, kann man da nicht mit UCS-2 oä. rumwurschteln.
Das kommt auf den Text an.
Wenn ich mich in meinem Programm auf europäische Zeichen beschränke kann ich UTF-16 nehmen und bin trotzdem Unicode-kompatibel. Unicode schreibt ja nur die Kodierung vor (also den numerischen Wert eines Zeichens), sowie einige Umwandlungen zwischen Caps und dergleichen, aber nicht die Anzahl Bytes pro Zeichen.
-
string, wstring
-
Mir ist gerade der Zusammenhang nicht klar. Für die allermeisten Texte reichen 16 Bit pro Zeichen aus und deshalb ist UTF-16 auch eigentlich die gebräuchlichste Codierung.
für die meisten würde sicher auch UTF-8 reichen
Wenn ich mich in meinem Programm auf europäische Zeichen beschränke kann ich UTF-16 nehmen und bin trotzdem Unicode-kompatibel.
UTF-16 ist ja eh Unicode kompatibel, da 32Bit auf 16Bit abgebildet werden
UCS-2 ist aber nicht UTF-16...
-
Es ging mir eigentlich nur um diesen Satz. Vielleicht wäre er weniger misverständlich gewesen, wenn du geschrieben hättest "... für vollständigen Unicode ..."
Fakt ist nur, für aktuelles Unicode braucht man 32Bit
Von UCS-2 hab ich auch nie geredet. Aber das ist jetzt Erbsenzählerei.
-
man braucht maximal eben 32Bit für Unicode, wie man die verteilt, ist egal
Leider ist unter Windows wchar_t idr. 16Bit groß, so dass man mit UTF-16 rumpröckern muss. Und wie gesagt, finde ich persönlich UTF-16 als schlechten Kompromiss aus UTF-8 und UTF-32.
-
kingruedi schrieb:
man braucht maximal eben 32Bit für Unicode, wie man die verteilt, ist egal
Leider ist unter Windows wchar_t idr. 16Bit groß, so dass man mit UTF-16 rumpröckern muss. Und wie gesagt, finde ich persönlich UTF-16 als schlechten Kompromiss aus UTF-8 und UTF-32.
Nein, wie ich bereits geschrieben habe, hängt es vom Text und den verwendeten Zeichen ab, wieviel Bits man braucht. Unicode schreibt den numerischen Wert vor und nicht, dass man 4 Bytes lesen muss, um ein Zeichen zu haben.
Das hat auch mit "verteilen" nichts zu tun. Wenn ein Zeichen x den Code \uAC04 hat, dann kann ich UTF-16 für die Kodierung verwenden und es ist trotzdem Unicode-codiert.UTF-16 reicht zum Glück fast immer. Ich hätte nichts dagegen, wenn Windows und Java UTF-32 verwenden würden, aber jetzt ist es nun mal leider so und es ist wenigstens ist es schon mal deutlich besser als ANSI.
Bevor wir UTF-32 einführen, müssen wir erstmal alle Leute davon überzeugen, überhaupt Unicode zu verwenden. Das wird noch lange genug dauern, bis wir so weit sind.
Es ist btw. nicht direkt ein Kompromiss, die Einführung von UTF-32 war zunächst gar nicht erst geplant, weil man dachte 2 Bytes wären genug. Kann man irgendwo auf unicode.org nachlesen.
-
wie gesagt, es geht darum, das man 32Bit braucht, dass man auch mit Multibyte Sequenzen da tricksen kann ist eine andere Sache, aber die brauchen eben auch 32Bit im Worst-Case
UCS-2 war der Unicode Standard, der 2 Byte erwartet hat. Deswegen ist es ja bei Windows so, dass wchar_t als Unicode Typ 2 Byte hat. Da es mittlerweile einen neuen Unicode Standard gibt, musst du dann eben UTF-16 nehmen um Unicode kompatibel zu sein. Und das bringt Probleme mit, da es eben ein Multibyte Format ist und so zB. nicht in basic_string gespeichert werden kann und mehr Laufzeitkosten hat, da zB. Dinge wie die Länge eines Strings zu bestimmen kompilizierter werden. Und wenn man Speicherplatz sparen will ist UTF-8 besser. Deswegen finde ich, dass UTF-16 ein schlechter Kompromiss ist, aber das ist wohl die Folge des veralteten UCS-2 Unicode Standards.
-
für die meisten würde sicher auch UTF-8 reichen
Wieso das? Das gilt vielleicht für Europa, Asien ist aber nicht gerade klein und hat auch eine entsprechende Bedeutung.
Lustig ist z.B. auch, das UTF-8-Strings bei europäischen Texten meist kürzer sind (vom Platzbedarf), als UTF-16-Strings, bei asiatischen Texten ist es aber genau umgekeht, da meist 3 Bytes benötigt werden und bei UTF-16 meistens dann nur 2.Wie auch immer, ein einzelner 2 Byte Block reicht nicht um ein Unicode-Zeichen zu enthalten. Das ändert aber nichts daram, dass ich Texte UTF-16 encodieren kann, wobei der Platzbedarf dann aber nicht von der Anzahl der zeichen alleine bestimmt wird, sondern auch davon, welche Zeichen verwendet werden. Und wstring ist nicht dafür geeignet.
-
Wie auch immer, ein einzelner 2 Byte Block reicht nicht um ein Unicode-Zeichen zu enthalten. Das ändert aber nichts daram, dass ich Texte UTF-16 encodieren kann, wobei der Platzbedarf dann aber nicht von der Anzahl der zeichen alleine bestimmt wird, sondern auch davon, welche Zeichen verwendet werden. Und wstring ist nicht dafür geeignet.
ich hab nichts anderes behauptet.