Wie ist der (innere)Aufbau einer String-Klasse?
-
UTF-8 Support kommt in C++0x.
@wxSkip
Der ursprüngliche Code wird ja nicht verdoppelt. Nichtmal das Binary, da ja nur benötigte Methoden instanziiert werden müssen und auch hier kann ein Compiler gemeinsamen Code reduzieren.swswws schrieb:
rüdiger schrieb:
swswws schrieb:
Und wegen der Untauglichkeit von std::string in Verbindung mit Internationalisierung gibt es mit std::wstring praktische eine Verdoppelung.
wstring und string sind beide nur ein typedef für basic_string.
Ja und schon die Tatsache, dass es beide gibt ist Müll. Schreibst du Funktionen denen du als Parameter wstring, string oder basic_string übergibst?
Nein, es ist nicht Müll. wstring hat enorme Speicheranforderungen (4byte für ein Zeichen für aktuellen Unicode), warum sollte man dafür bezahlen, wenn man es nicht braucht? Das verstößt gegen die Philosophie von C++. Dank Templates kann man den Code ja trotzdem für beide (und sogar noch viel mehr) Fälle schreiben. Daher sehe ich hier kein Problem. Solange man nicht zeichenweise auf Unicode-Strings arbeiten muss ist wstring einfach zu viel.
-
swswws schrieb:
Ja und schon die Tatsache, dass es beide gibt ist Müll. Schreibst du Funktionen denen du als Parameter wstring, string oder basic_string übergibst?
Du möchtest jetzt nicht ernsthaft kritisieren, dass es verschiedene char-Typen gibt? Hast du dann auch was gegen long int, short oder gar size_t, nur weil man (lies: DU) sowieso nur int als Parameter übergibt? Und was ist so schlimm daran, dass es jetzt wstring gibt, dass es als Müll bezeichnet werden muss?
-
rüdiger schrieb:
UTF-8 Support kommt in C++0x.
Hehe, guck mal auf den Wecker welches Jahrzehnt wir inzwischen haben
rüdiger schrieb:
wstring hat enorme Speicheranforderungen (4byte für ein Zeichen für aktuellen Unicode),
Wie man sieht hast du wohl nicht so viel Ahnung von sowas, gell?
-
stringkenner schrieb:
rüdiger schrieb:
UTF-8 Support kommt in C++0x.
Hehe, guck mal auf den Wecker welches Jahrzehnt wir inzwischen haben
Na wahnsinn... Es sollte 200x rauskommen hat sich aber verzögert. Trotzdem hat sich die Benennung "C++0x" eingebürgert. Toll, nennen wir ihn jetzt extra für dich C++1x, ok?
rüdiger schrieb:
wstring hat enorme Speicheranforderungen (4byte für ein Zeichen für aktuellen Unicode),
Wie man sieht hast du wohl nicht so viel Ahnung von sowas, gell?
Aber selber?
Aktueller Unicode -> UTF32. 32 Bit = 4 Byte. Hammer, oder?
-
rüdiger schrieb:
swswws schrieb:
rüdiger schrieb:
swswws schrieb:
Und wegen der Untauglichkeit von std::string in Verbindung mit Internationalisierung gibt es mit std::wstring praktische eine Verdoppelung.
wstring und string sind beide nur ein typedef für basic_string.
Ja und schon die Tatsache, dass es beide gibt ist Müll. Schreibst du Funktionen denen du als Parameter wstring, string oder basic_string übergibst?
Nein, es ist nicht Müll. wstring hat enorme Speicheranforderungen (4byte für ein Zeichen für aktuellen Unicode), warum sollte man dafür bezahlen, wenn man es nicht braucht? Das verstößt gegen die Philosophie von C++. Dank Templates kann man den Code ja trotzdem für beide (und sogar noch viel mehr) Fälle schreiben. Daher sehe ich hier kein Problem. Solange man nicht zeichenweise auf Unicode-Strings arbeiten muss ist wstring einfach zu viel.
Man kann einfach zwei Pointer in den String machen und je nachdem was man zuweist den einen oder den anderen verwenden.
Machen die dann mit dem neuen Standard noch nen String für utf8? std::u8string? Verbraucht dann auch nur soviel Speicher wie der UTF-8 Codierte Text?
l'abra d'or schrieb:
swswws schrieb:
Ja und schon die Tatsache, dass es beide gibt ist Müll. Schreibst du Funktionen denen du als Parameter wstring, string oder basic_string übergibst?
Du möchtest jetzt nicht ernsthaft kritisieren, dass es verschiedene char-Typen gibt? Hast du dann auch was gegen long int, short oder gar size_t, nur weil man (lies: DU) sowieso nur int als Parameter übergibt? Und was ist so schlimm daran, dass es jetzt wstring gibt, dass es als Müll bezeichnet werden muss?
Dumm, oder warum erfindest du soviel scheiß?
-
l'abra d'or schrieb:
stringkenner schrieb:
rüdiger schrieb:
UTF-8 Support kommt in C++0x.
Hehe, guck mal auf den Wecker welches Jahrzehnt wir inzwischen haben
Na wahnsinn... Es sollte 200x rauskommen hat sich aber verzögert. Trotzdem hat sich die Benennung "C++0x" eingebürgert. Toll, nennen wir ihn jetzt extra für dich C++1x, ok?
Ja, danke, sieht besser aus. Neben der Bezeichnung war das aber auch eher als Provokation zu verstehen, dass wir bereits 10 Jahre nach der Jahrtausendwende haben und std C++ noch immer keinen richtigen Unicode Support hat
rüdiger schrieb:
wstring hat enorme Speicheranforderungen (4byte für ein Zeichen für aktuellen Unicode),
Wie man sieht hast du wohl nicht so viel Ahnung von sowas, gell?
Aber selber?
Aktueller Unicode -> UTF32. 32 Bit = 4 Byte. Hammer, oder?Blödsinn, Unicode ist erstmal nur eine Spezifikation. Welches Encoding ich verwende um Unicode darzustellen hat damit erstmal überhaupt nichts zu tun. Ich kann nämlich mit jeder UTF Version, also UTF-8, UTF-16 oder UTF-32 _alle_ Unicode Zeichen darstellen. Java benutzt intern z.B. UTF-16, jeder char ist 2 byte lang und damit kann ich alle Unicode Zeichen darstellen (und das seit 15 Jahren - o schreck)
Wenn mir dann jemand daherkommt und im Jahr 2010 erzählen will UTF codierte Texte verbrauchen zuviel Speicherplatz und deswegen sollen wir uns alle in den Fuß schießen (oder nur noch Englische Software entwickeln) kann man nur noch weinen.
-
swswws schrieb:
Man kann einfach zwei Pointer in den String machen und je nachdem was man zuweist den einen oder den anderen verwenden.
Das ist ja ein toller Vorschlag. Und weil es UTF16 und UTF32 gibt, machen wir uns auch gleich soviele, dass alles abgedeckt werden kann?
Und die Verwendung wird dann grauenhaft. Ein string::at() liefert dann was zurück? Ständige Prüfungen, welcher String gerade verwendet wird? Ein std::universal_string wird übergeben, und der Verwender erdreistet sich, einen wchar-array zu setzen, obwohl gerade ein char-array gespeichert ist? Wunderbar, jetzt muss erstmal intern der String umkopiert und umkodiert werden. Dann kannst du dich wenigstens wieder beschweren, dass C++ so inperformant ist
l'abra d'or schrieb:
Dumm, oder warum erfindest du soviel scheiß?
Wahrscheinlich bin ich dumm, weil ich immer noch auf deine Posts antworte, weil du eh intelligenter zu sein scheinst als das Komitee, das sich seit Jahren darum bemüht, dass C++ besser wird. Kannst dich ja hinsetzen und ein ++C++ entwickeln...
-
l'abra d'or schrieb:
swswws schrieb:
Man kann einfach zwei Pointer in den String machen und je nachdem was man zuweist den einen oder den anderen verwenden.
Das ist ja ein toller Vorschlag. Und weil es UTF16 und UTF32 gibt, machen wir uns auch gleich soviele, dass alles abgedeckt werden kann?
Und die Verwendung wird dann grauenhaft. Ein string::at() liefert dann was zurück?Tja, überleg mal.
l'abra d'or schrieb:
Wahrscheinlich bin ich dumm, weil ich immer noch auf deine Posts antworte, weil du eh intelligenter zu sein scheinst als das Komitee, das sich seit Jahren darum bemüht, dass C++ besser wird. Kannst dich ja hinsetzen und ein ++C++ entwickeln...
Ich nehm einfach ein anderes Framework, dass keine zwei Strings braucht. C++ besteht ja zum Glück nicht nur aus std::
-
stringerkenner schrieb:
Blödsinn, Unicode ist erstmal nur eine Spezifikation. Welches Encoding ich verwende um Unicode darzustellen hat damit erstmal überhaupt nichts zu tun. Ich kann nämlich mit jeder UTF Version, also UTF-8, UTF-16 oder UTF-32 _alle_ Unicode Zeichen darstellen. Java benutzt intern z.B. UTF-16, jeder char ist 2 byte lang und damit kann ich alle Unicode Zeichen darstellen (und das seit 15 Jahren - o schreck)
Wenn mir dann jemand daherkommt und im Jahr 2010 erzählen will UTF codierte Texte verbrauchen zuviel Speicherplatz und deswegen sollen wir uns alle in den Fuß schießen (oder nur noch Englische Software entwickeln) kann man nur noch weinen.Ja, für Unicode gibt es diverse Encodings. Aber wenn du gelesen hättest, was ich schreibe, dann würdest du sehen, dass ich mich konkret auf die Darstellung in wstring beziehe:
rüdiger schrieb:
wstring hat enorme Speicheranforderungen (4byte für ein Zeichen für aktuellen Unicode),
Und wstring kann keine Multibytezeichensätze (wie zB UTF-8). Daher braucht wstring eben 4 Byte. Natürlich kann man einen UTF-8/16-String nehmen, wenn man mit langsamen Zeichenweise-Zugriff leben kann. Daher auch die spätere Einschränkung
rüdiger schrieb:
Solange man nicht zeichenweise auf Unicode-Strings arbeiten muss ist wstring einfach zu viel.
Also kein Grund unfreundlich zu werden. Lieber einmal richtig lesen
.
-
stringkenner schrieb:
rüdiger schrieb:
wstring hat enorme Speicheranforderungen (4byte für ein Zeichen für aktuellen Unicode),
Wie man sieht hast du wohl nicht so viel Ahnung von sowas, gell?
Aber selber?
Aktueller Unicode -> UTF32. 32 Bit = 4 Byte. Hammer, oder?Blödsinn, Unicode ist erstmal nur eine Spezifikation. Welches Encoding ich verwende um Unicode darzustellen hat damit erstmal überhaupt nichts zu tun. Ich kann nämlich mit jeder UTF Version, also UTF-8, UTF-16 oder UTF-32 _alle_ Unicode Zeichen darstellen. Java benutzt intern z.B. UTF-16, jeder char ist 2 byte lang und damit kann ich alle Unicode Zeichen darstellen (und das seit 15 Jahren - o schreck)
uhm.... nein. Du verwechselst UTF-16 und UCS-2. Mit UTF-16 kannst du nicht jedes Zeichen in 2 chars speichern, lediglich die des BMP
-
Blue-Tiger schrieb:
stringkenner schrieb:
Blödsinn, Unicode ist erstmal nur eine Spezifikation. Welches Encoding ich verwende um Unicode darzustellen hat damit erstmal überhaupt nichts zu tun. Ich kann nämlich mit jeder UTF Version, also UTF-8, UTF-16 oder UTF-32 _alle_ Unicode Zeichen darstellen. Java benutzt intern z.B. UTF-16, jeder char ist 2 byte lang und damit kann ich alle Unicode Zeichen darstellen (und das seit 15 Jahren - o schreck)
uhm.... nein. Du verwechselst UTF-16 und UCS-2. Mit UTF-16 kannst du nicht jedes Zeichen in 2 chars speichern, lediglich die des BMP
falsch, kannst du aber auch hier nachlesen: http://en.wikipedia.org/wiki/UTF-16/UCS-2
-
stringkenner schrieb:
Blue-Tiger schrieb:
stringkenner schrieb:
Blödsinn, Unicode ist erstmal nur eine Spezifikation. Welches Encoding ich verwende um Unicode darzustellen hat damit erstmal überhaupt nichts zu tun. Ich kann nämlich mit jeder UTF Version, also UTF-8, UTF-16 oder UTF-32 _alle_ Unicode Zeichen darstellen. Java benutzt intern z.B. UTF-16, jeder char ist 2 byte lang und damit kann ich alle Unicode Zeichen darstellen (und das seit 15 Jahren - o schreck)
uhm.... nein. Du verwechselst UTF-16 und UCS-2. Mit UTF-16 kannst du nicht jedes Zeichen in 2 chars speichern, lediglich die des BMP
falsch, kannst du aber auch hier nachlesen: http://en.wikipedia.org/wiki/UTF-16/UCS-2
Uhm... ja, den link kenn ich. Lies ihn mal. Da steht auch genau das drin, was ich vorhin gesagt hab: "For characters in the Basic Multilingual Plane (BMP) the resulting encoding is a single 16-bit word. For characters in the other planes, the encoding will result in a pair of 16-bit words, together called a surrogate pair". Magst nen Keks?
-
Blue-Tiger schrieb:
stringkenner schrieb:
Blue-Tiger schrieb:
stringkenner schrieb:
Blödsinn, Unicode ist erstmal nur eine Spezifikation. Welches Encoding ich verwende um Unicode darzustellen hat damit erstmal überhaupt nichts zu tun. Ich kann nämlich mit jeder UTF Version, also UTF-8, UTF-16 oder UTF-32 _alle_ Unicode Zeichen darstellen. Java benutzt intern z.B. UTF-16, jeder char ist 2 byte lang und damit kann ich alle Unicode Zeichen darstellen (und das seit 15 Jahren - o schreck)
uhm.... nein. Du verwechselst UTF-16 und UCS-2. Mit UTF-16 kannst du nicht jedes Zeichen in 2 chars speichern, lediglich die des BMP
falsch, kannst du aber auch hier nachlesen: http://en.wikipedia.org/wiki/UTF-16/UCS-2
Uhm... ja, den link kenn ich. Lies ihn mal. Da steht auch genau das drin, was ich vorhin gesagt hab: "For characters in the Basic Multilingual Plane (BMP) the resulting encoding is a single 16-bit word. For characters in the other planes, the encoding will result in a pair of 16-bit words, together called a surrogate pair". Magst nen Keks?
Versteh jetzt nicht ganz inwiefern das meinen Aussagen widerspricht. Dass ein char 2 byte (GLEICH 16 BIT) lang ist weißt du? Hab ich auch schon auf der letzten Seite erwähnt.
-
Versteh jetzt nicht ganz inwiefern das meinen Aussagen widerspricht.
Ganz einfach
jeder char ist 2 byte lang und damit kann ich alle Unicode Zeichen darstellen
Ein char in Java ist vielleicht 2 Byte groß. Aber mit einem char kann man eben nicht alle Unicodezeichen darstellen. Für manche Zeichen braucht man 2 chars (also 4 Byte).
-
Außer dass C++ objektorientiert ist gibt es doch nicht soo viele Unterschiede
zu reinem C. Wieso ist C für Treiber Programmierung besser als C++ ?Objektorientierung soll doch besser sein ? Versteh ich grad nicht ?
-
blurry333 schrieb:
Wieso ist C für Treiber Programmierung besser als C++ ?
Ist es nicht.
-
sorry ich wollte eigentlich auf einen anderen thread antworten , aber nun ist es halt hier gelandet.
Jedenfalls verwendet man für Treiber fast immer prozedurales C.
Muss ja einen Grund haben.
-
blurry333 schrieb:
sorry ich wollte eigentlich auf einen anderen thread antworten , aber nun ist es halt hier gelandet.
Jedenfalls verwendet man für Treiber fast immer prozedurales C.
Muss ja einen Grund haben.
