Unicode, UTF8 und Multiybyte - etwas verwirrt.

rüdiger schrieb:

Pedobear schrieb:

wchar_t bzw. L"" sind 16 Bit breit, also zum speichern von UTF-16

Nein! wchar_t ist eher für fixedsize Zeichensätze gedacht. UTF-16 dort reinzustecken ist eher eine Aushilfslösung.

Diese Aushilfslösung wird aber von vielen Windows Programmieren verwendet. Schau dir nur mal unseren Artikel an.

otze

Pedobear schrieb:

wchar_t ist nicht immer 32 Bit breit! Also ist es nicht portabel und deprecated! Jetzt verstanden?

Sag mir, wie du auf anderem wege mit Betriebssystemfunktionen arbeiten willst. Wenn die nen wchar_t wollen, dann hast du ihnen einen wchar_t zu geben, sonst quittieren sie den dienst.

otze schrieb:

Pedobear schrieb:

wchar_t ist nicht immer 32 Bit breit! Also ist es nicht portabel und deprecated! Jetzt verstanden?

Sag mir, wie du auf anderem wege mit Betriebssystemfunktionen arbeiten willst. Wenn die nen wchar_t wollen, dann hast du ihnen einen wchar_t zu geben, sonst quittieren sie den dienst.

Ich sprach von Portabilität. Wenn man portabel sein möchte, verwendet man für Gewöhnlich auch keine Betriebssystemfunktionen sondern die Standardbibliothek oder boost oder etwsa ähnliches.
Wenn du allerdings nicht portabel sein möchtest, weißt du ja wie groß deine Datentypen sind und kannst auch wchar_t benutzen. Dann bleibst du dann allerdings auf Windows beschränkt.

also, wenn alles was nicht portabel ist auch deprecated ist, dann ist ja fast alles in C++ deprecated.

ähm schrieb:

also, wenn alles was nicht portabel ist auch deprecated ist, dann ist ja fast alles in C++ deprecated.

Nö, C++ ist eigentlich sehr portabel.

firefly

Pedobear schrieb:

otze schrieb:

Pedobear schrieb:

wchar_t ist nicht immer 32 Bit breit! Also ist es nicht portabel und deprecated! Jetzt verstanden?

Sag mir, wie du auf anderem wege mit Betriebssystemfunktionen arbeiten willst. Wenn die nen wchar_t wollen, dann hast du ihnen einen wchar_t zu geben, sonst quittieren sie den dienst.

Ich sprach von Portabilität. Wenn man portabel sein möchte, verwendet man für Gewöhnlich auch keine Betriebssystemfunktionen sondern die Standardbibliothek oder boost oder etwsa ähnliches.
Wenn du allerdings nicht portabel sein möchtest, weißt du ja wie groß deine Datentypen sind und kannst auch wchar_t benutzen. Dann bleibst du dann allerdings auf Windows beschränkt.

und was ist mit den mb*wc(s) und den wc* funktionen in der standard c library?
die gibt es beide unter Windows und unter Linux(für andere Betriebsysteme wie *BSD und andere weis ich es nicht) und jeweils mit wchar_t als einen der erwarteten Parameter.
z.b. mbstrtowcs und wcstombs

firefly schrieb:

Pedobear schrieb:

otze schrieb:

Pedobear schrieb:

wchar_t ist nicht immer 32 Bit breit! Also ist es nicht portabel und deprecated! Jetzt verstanden?

Sag mir, wie du auf anderem wege mit Betriebssystemfunktionen arbeiten willst. Wenn die nen wchar_t wollen, dann hast du ihnen einen wchar_t zu geben, sonst quittieren sie den dienst.

Ich sprach von Portabilität. Wenn man portabel sein möchte, verwendet man für Gewöhnlich auch keine Betriebssystemfunktionen sondern die Standardbibliothek oder boost oder etwsa ähnliches.
Wenn du allerdings nicht portabel sein möchtest, weißt du ja wie groß deine Datentypen sind und kannst auch wchar_t benutzen. Dann bleibst du dann allerdings auf Windows beschränkt.

und was ist mit den mb*wc(s) und den wc* funktionen in der standard c library?
die gibt es beide unter Windows und unter Linux(für andere Betriebsysteme wie *BSD und andere weis ich es nicht) und jeweils mit wchar_t als einen der erwarteten Parameter.
z.b. mbstrtowcs und wcstombs

Die sind für leagcy Programme gedacht, die noch mit alten Codierungen umgehen müssen. Nichts, was man in modernen Programmen verwenden sollte..

firefly

Pedobear schrieb:

firefly schrieb:

Pedobear schrieb:

otze schrieb:

Pedobear schrieb:

wchar_t ist nicht immer 32 Bit breit! Also ist es nicht portabel und deprecated! Jetzt verstanden?

Sag mir, wie du auf anderem wege mit Betriebssystemfunktionen arbeiten willst. Wenn die nen wchar_t wollen, dann hast du ihnen einen wchar_t zu geben, sonst quittieren sie den dienst.

Ich sprach von Portabilität. Wenn man portabel sein möchte, verwendet man für Gewöhnlich auch keine Betriebssystemfunktionen sondern die Standardbibliothek oder boost oder etwsa ähnliches.
Wenn du allerdings nicht portabel sein möchtest, weißt du ja wie groß deine Datentypen sind und kannst auch wchar_t benutzen. Dann bleibst du dann allerdings auf Windows beschränkt.

und was ist mit den mb*wc(s) und den wc* funktionen in der standard c library?
die gibt es beide unter Windows und unter Linux(für andere Betriebsysteme wie *BSD und andere weis ich es nicht) und jeweils mit wchar_t als einen der erwarteten Parameter.
z.b. mbstrtowcs und wcstombs

Die sind für leagcy Programme gedacht, die noch mit alten Codierungen umgehen müssen. Nichts, was man in modernen Programmen verwenden sollte..

und was soll man dann deiner Meinung nach in modernen Programmen verwenden?

firefly schrieb:

Pedobear schrieb:

firefly schrieb:

Pedobear schrieb:

otze schrieb:

Pedobear schrieb:

wchar_t ist nicht immer 32 Bit breit! Also ist es nicht portabel und deprecated! Jetzt verstanden?

Sag mir, wie du auf anderem wege mit Betriebssystemfunktionen arbeiten willst. Wenn die nen wchar_t wollen, dann hast du ihnen einen wchar_t zu geben, sonst quittieren sie den dienst.

Ich sprach von Portabilität. Wenn man portabel sein möchte, verwendet man für Gewöhnlich auch keine Betriebssystemfunktionen sondern die Standardbibliothek oder boost oder etwsa ähnliches.
Wenn du allerdings nicht portabel sein möchtest, weißt du ja wie groß deine Datentypen sind und kannst auch wchar_t benutzen. Dann bleibst du dann allerdings auf Windows beschränkt.

und was ist mit den mb*wc(s) und den wc* funktionen in der standard c library?
die gibt es beide unter Windows und unter Linux(für andere Betriebsysteme wie *BSD und andere weis ich es nicht) und jeweils mit wchar_t als einen der erwarteten Parameter.
z.b. mbstrtowcs und wcstombs

Die sind für leagcy Programme gedacht, die noch mit alten Codierungen umgehen müssen. Nichts, was man in modernen Programmen verwenden sollte..

und was soll man dann deiner Meinung nach in modernen Programmen verwenden?

Wie ich oben schon sagte: UTF-8 (char*) zum speichern von Unicode, da es die kürzeste der Unicode-Codierungen ist und UTF-32 (basic_string<uint32_t>) zum bearbeiten von Unicode, da man dann keine Probleme mit variabler Zeichenbreite hat.

.filmor

Pedobear schrieb:

UTF-32 (basic_string<uint32_t>) zum bearbeiten von Unicode, da man dann keine Probleme mit variabler Zeichenbreite hat.

Hehe. Was ein frommer Traum. Aber den musst du leider begraben (es sei denn, du treibst dich ausschließlich im 8859-Gebiet rum und brauchst deshalb sowieso kein Unicode ;)). http://en.wikipedia.org/wiki/Unicode_normalization

Gibt es eigentlich eine Library die mir einen Unicode String in ein bitmap* rendert?

* Nicht als Datei sondern im Speicher z.B. als struct bitmap { int width, height; char *data };

akari

Hallo

Ja jede beliebige Grafikbibliothek mit einer Text-Funktion. Zum Beispiel die WinAPI kann mit DrawText in ein temporäres HBITMAP zeichnen.

bis bald
akari

Damit man nicht an eine bestimmte Grafiklibrary gebunden ist empfehle ich eine reine Text-Render-Library wie FreeType zu verwenden.
Ich weiß allerdings nicht, ob FreeType mit zusammengesetzten Symbolen zurecht kommt. Weiß da jemand genaueres?

rüdiger

Pedobear schrieb:

Die sind für leagcy Programme gedacht, die noch mit alten Codierungen umgehen müssen. Nichts, was man in modernen Programmen verwenden sollte..

Nenne bitte eine Quelle. Ich halte deine Aussagen so einfach für totalen Blödsinn.

Interessierte schrieb:

Gibt es eigentlich eine Library die mir einen Unicode String in ein bitmap* rendert?

Freetype2 und ansonsten so gut wie jeder aktuelle Fontrenderer.

Artchi

Pedobear! Deine Meinung ist ziemlich irrelevant. Wenn etwas deprecated ist, dann hat das nur und nur alleine die ISO-C++-Norm zu bestimmen. Ob dir wchar_t persönlich gefällt oder missfällt, interessiert nicht die Bohne.

wchar_t ist jedenfalls nicht deprecated. Kann auch garnicht gehen, da es seit 1998 keinen neuen Standard gab (nur 2003 eine Korrektur).

Es halt auch eine Frage des guten Stils, was man verwendet. Und wchar_t und Konsorten sind eher keine guter Stil. Aber macht es meinetwegen, wie ihr wollt. Kommt dann aber hinterher nicht angerannt, euer Programm sei nicht portabel.

Sinnlose Diskussion beendet**.**

Meister "ich weiß alles" weiß wohl doch nicht alles und beendet deshalb mal lieber die Diskussion...

akari

Hallo

Pedobear schrieb:

Es halt auch eine Frage des guten Stils, was man verwendet. Und wchar_t und Konsorten sind eher keine guter Stil. Aber macht es meinetwegen, wie ihr wollt. Kommt dann aber hinterher nicht angerannt, euer Programm sei nicht portabel.

Sinnlose Diskussion beendet**.**

Ja was für eine Frechheit von den Entwicklern von wxWidgets. Bauen die doch ihre String-Klasse im Unicode-Modus auf wchar_t auf und behaupten dann das wäre portabel!

bis bald
akari

akari schrieb:

Hallo

Pedobear schrieb:

Es halt auch eine Frage des guten Stils, was man verwendet. Und wchar_t und Konsorten sind eher keine guter Stil. Aber macht es meinetwegen, wie ihr wollt. Kommt dann aber hinterher nicht angerannt, euer Programm sei nicht portabel.

Sinnlose Diskussion beendet**.**

Ja was für eine Frechheit von den Entwicklern von wxWidgets. Bauen die doch ihre String-Klasse im Unicode-Modus auf wchar_t auf und behaupten dann das wäre portabel!

bis bald
akari

lol, die verwenden nur die ersten 16 bits des wchar_t woduch auf zb linux (sizeof(wchar_t)=4) die hälfte des speichers verschwendet wird..

Artchi schrieb:

Deine Meinung ist ziemlich irrelevant.

lol, du meinst sie is für dich irrelevant. wenns dich net interessiert poste hat nich..