von Java nach C++

SoGehtEs schrieb:

Woher weißt du viele Zeichen (nicht bytes) dein String hat, wenn du nur einen Haufen von Bytes ohne angabe des Encodings hast?

Ich habe den Kram doch da rein getan, also weiß ich auch, welche Kodierung ich dabei verwendet habe. Vernünftigerweise natürlich UTF-8. Eine Funktion zu schreiben, die mir die Anzahl an Codepoints in einem UTF-8-String zurückgibt, ist trivial. Wo ist jetzt das Problem?

Wenn ich ständig wahlfreien Zugriff auf die Codepoints benötigen sollte, wandle ich eben bei Bedarf vorher zu UCS-4 in einem basic_string<uint32> o.ä. um.

@Bitte ein Bit: warum sollte basic_string<char> nicht für UTF-8 geeignet sein?

…

dot

SoGehtEs schrieb:

Woher weißt du viele Zeichen (nicht bytes) dein String hat, wenn du nur einen Haufen von Bytes ohne angabe des Encodings hast?

Das weißt du auch in Java nicht. Überhaupt, die Frage wieviele "Zeichen" ein String hat ist rein Prinzipiell alles andere als einfach zu beantworten. Was genau verstehst du denn unter einem Zeichen? Ein Code Unit? Einen Code Point? Ein Grapheme? Einen Abstract Character?

knivil

Eine Funktion zu schreiben, die mir die Anzahl ...

Deswegen ist std::basic_string genauso gut wie std::vector, da die Standardfunktionalitaet von std::basic_string nicht benutzt werden kann. Eine simple Methode length muss selbst implementiert werden. std::basic_string ist ungeeignet und kann maximal als untergeordneter Container verwendet werden.

Gregor

dot schrieb:

Aha und inwiefern ist dieser String, "den (fast) jede Library verwendet und man nicht ständig konvertieren muss", besser für Internationalisierung als std::basic_string!?

Der entscheidende Punkt bei Java ist die Standardbibliothek. Hier kriegt man von Anfang an eine erhebliche Infrastruktur fuer viele Dinge mitgeliefert. Das betrifft auch die Unterstuetzung der Internationalisierung. Javaentwickler nutzen praktisch immer java.lang.String, weil man weiss, dass es in der Standardbibliothek jede Menge Klassen, Methoden und so weiter gibt, die darauf ausgelegt sind. Externe Bibliotheken nutzen praktisch aus gleichem Grund die gleichen Strings. Wenn es in Java um Strings geht, ist java.lang.String deshalb die erste Wahl. Alles andere muss man erstmal rechtfertigen. Warum sollte man sich aus der massiven Unterstuetzung dieser Klasse ausklinken? Meistens findet man keinen Grund, der das rechtfertigen wuerde.

Ich habe keine Ahnung, wie die Situation diesbezueglich in C++ ist. C++ hat eine schlankere Standardbibliothek, so dass es vielleicht weniger offensichtlich ist, auf welcher Basis man seinen eigenen Code schreiben sollte. Ich vermute einfach mal, dass man deshalb haeufig externe Bibliotheken nutzt, die nicht unbedingt zu einander passen. Man wird also vermutlich mehr damit beschaeftigt sein, zwischen unterschiedlichen Bibliotheken zu vermitteln.

dot schrieb:

std::basic_string ist rein prinzipiell nicht mehr oder weniger schlecht für Unicode geeignet als der Java oder .NET String auch, man ist sich dieser Einschränkungen im Umfeld von C++ offenbar einfach nur wesentlich besser bewusst...

Wenn man sich gewisser Einschraenkungen nicht bewusst ist, dann meistens deshalb, weil sie im gegebenen Umfeld nicht relevant sind.

knivil schrieb:

Eine Funktion zu schreiben, die mir die Anzahl ...

Deswegen ist std::basic_string genauso gut wie std::vector, da die Standardfunktionalitaet von std::basic_string nicht benutzt werden kann. Eine simple Methode length muss selbst implementiert werden.

Ist doch Quatsch. Meist will ich doch gerade die Länge in Byte wissen. Was bringt mir denn die Anzahl der Codepoints? Was fange ich damit an? Siehe dot.

Die meisten anderen basic_string-Funktionen und Methoden kann ich doch prima mit UTF-8 verwenden. Ich seh' das Problem nicht.

dot schrieb:

SoGehtEs schrieb:

Woher weißt du viele Zeichen (nicht bytes) dein String hat, wenn du nur einen Haufen von Bytes ohne angabe des Encodings hast?

Das weißt du auch in Java nicht. Überhaupt, die Frage wieviele "Zeichen" ein String hat ist rein Prinzipiell alles andere als einfach zu beantworten. Was genau verstehst du denn unter einem Zeichen? Ein Code Unit? Einen Code Point? Ein Grapheme? Einen Abstract Character?

Na Unicode-Zeichen. Mit UTF-8 stellt man diese dar. http://de.wikipedia.org/wiki/UTF-8
Ich kenn mich mit Java Strings nicht so genau aus, aber ich bin mir sehr sicher, dass es da funktioniert. Mit QStrings geht es mal richtig.

Übrigens habe ich hier mal einen Test gemacht, ob hier jemand sich an die angeblich so bekannte Regel hält, dass std::string angeblich immer UTF-8 enthält.
http://www.c-plusplus.net/forum/319361
Keiner hat den UTF-8 Bug erkannt, bzw UTF-8 auch nur erwähnt.

badgerbadgerbadger schrieb:

Die meisten anderen basic_string-Funktionen und Methoden kann ich doch prima mit UTF-8 verwenden. Ich seh' das Problem nicht.

Du willst das Problem nicht sehen.

Ethon

std::string + http://utfcpp.sourceforge.net/

knivil

h[1] = 'W'

Damit meine ich das zweite Zeichen der Zeichenkette. Zeichen ist kein Synonym fuer Byte.

Was soll passieren, wenn h eine utf-8 Zeichenkette ist? Was kann alles passieren? Und ist das im Einklang mit den Invarianten/Nachbedingungen zu bringen, die fuer std::string laut Standard garantiert werden?

dot

SoGehtEs aka MichaelBr schrieb:

dot schrieb:

SoGehtEs schrieb:

Woher weißt du viele Zeichen (nicht bytes) dein String hat, wenn du nur einen Haufen von Bytes ohne angabe des Encodings hast?

Das weißt du auch in Java nicht. Überhaupt, die Frage wieviele "Zeichen" ein String hat ist rein Prinzipiell alles andere als einfach zu beantworten. Was genau verstehst du denn unter einem Zeichen? Ein Code Unit? Einen Code Point? Ein Grapheme? Einen Abstract Character?

Na Unicode-Zeichen. Mit UTF-8 stellt man diese dar. http://de.wikipedia.org/wiki/UTF-8
Ich kenn mich mit Java Strings nicht so genau aus, aber ich bin mir sehr sicher, dass es da funktioniert. Mit QStrings geht es mal richtig.

Ein Java char entspricht einem UTF-16 Code Unit und keinem Code Point (und beides ist weit entfernt von dem, was du dir unter einem "Zeichen" vorstellst), der entsprechende Typ in C++ wäre char16_t und ein Java String ist mehr oder weniger nichts anderes als ein C++ std::basic_string<char16_t>...

SoGehtEs aka MichaelBr schrieb:

Übrigens habe ich hier mal einen Test gemacht, ob hier jemand sich an die angeblich so bekannte Regel hält, dass std::string angeblich immer UTF-8 enthält.
http://www.c-plusplus.net/forum/319361
Keiner hat den UTF-8 Bug erkannt, bzw UTF-8 auch nur erwähnt.

Der Code wär in Java genauso falsch...

java,gibts das immernoch? schrieb:

Wenn man mit Java programmiert, dann sind einige Punkte von vorneherein klar:
- man benötigt die JVM (die ich jetzt schon seit Jahren nicht mehr auf meinen Computer lasse - wenn ich bei der Installation eines Programms merke, dass das Programm die JVM braucht, installier ich es nicht, gleiches gilt für das Java-Browser-Plugin, das regelmäßig für schwere Sicherheitslücken sorgt)

Das Browser Plugin muss man ja nicht nutzen und an der JVM stören nur die Ladezeiten, die man aber auch hat, wenn man Programme mit fremden GUI Toolkits verwendet. Z.b. GTK+ unter Windows.

Ich mag die Java Programme TV-Browser, Minecraft und Eclipse und nutze sie auch.

- man ist vollständig abhängig von Oracle und deren Firmenpolitik

Das gilt doch nur für Sprachneuenwicklungen.

Wer nur ne konkrete JVM braucht, hat hier eine große Auswahl, einschließlich Open Source Varianten.

- es gibt neben der Oracle JVM noch diese OpenJDK, aber ob die tatsächlich eine Alternative ist, weiß ich nicht

Ich benutze immer das Original von Oracle, also die mit Hotspot.
Subjektiv empfinde ich sie nämlich schneller, als OpenJDK, aber ich könnte mich auch täuschen.
Der TV-Browser läuft auf beiden zufriedenstellened.

- die Programme werden, so gut sie noch geschrieben sind, verhältnismäßig langsam laufen

Bei den meisten Programme ist die Geschwindigkeit gar nicht so wichtig, sondern Wartbarkeit hat Vorrang.
Ob der Anwender seinen Firmendialog als C++ Lösung oder Java Lösung erhält macht hier keinen Unterschied, denn schneller Klicken als der Computer reagieren kann, kann der Nutzer sowieso nicht.

Und für Programme in denen Geschwindigkeit wichtig ist, kann man dann immer noch die dafür richtige Sprache einsetzen.

- Java bedeutet: ein bisschen Portabilität zugunsten der Geschwindigkeit

Dazu kommen noch:

+ Wartbarkeit
+ einheitliche umfangreiche Standard API ohne dabei zur Bloatware zu werden
+ gute Erlern- und Beherrschbarkeit aufgrund eines wesentlich kleineren Sprachumfangs als C++
+ schnellere Entwicklung der SW
+ geringere Fehlerträchtigkeit

- Java lässt sich nicht zur Betriebssystem-Entwicklung einsetzten

Richtig, dafür wurde es auch nicht gemacht.
Genauso wenig sollte man C++ zum Schreiben von Scripten verwenden.

Es ist nunmal so, dass keine Sprache ideal für alles ist aber es für jede Sprache einen Einsatzweck gibt, wofür sie sich besonders gut eignet.
Das trifft sowohl auf C++ als auch auf Java zu.

dot schrieb:

SoGehtEs aka MichaelBr schrieb:

Übrigens habe ich hier mal einen Test gemacht, ob hier jemand sich an die angeblich so bekannte Regel hält, dass std::string angeblich immer UTF-8 enthält.
http://www.c-plusplus.net/forum/319361
Keiner hat den UTF-8 Bug erkannt, bzw UTF-8 auch nur erwähnt.

Der Code wär in Java genauso falsch...

Ich wollte ja auch mal nur testen, wie es mit der angeblich so verbreiteten Verwendung von UTF-8 in einem std::string steht. Wie ich mir schon dachte, denkt eigentlich so gut wie keiner daran. Und sehr wahrscheinlich findest du auch einige C++ Libraries die std::string nicht als UTF-8 String behandeln. Steht das überhaupt im Standard, dass das so sein sollte?

knivil

Wer nur ne konkrete JVM braucht, hat hier eine große Auswahl, einschließlich Open Source Varianten.

Und wer JVM + JIT moechte?

Ob der Anwender seinen Firmendialog als C++ Lösung oder Java Lösung erhält macht hier keinen Unterschied

Wenn ich bewusst vorgehe, dann laufen meine C++ Programme out-of-the-box auf jedem Windows-PC (nein, ich rede hier nicht von windows 3.1).

ohne dabei zur Bloatware zu werden

Lol.

Hatten wir aber alles schon. ... Just another flame war.

Bitte ein Bit

@htgsdf

@Bitte ein Bit: So sieht das richtig aus:
std::basic_string<char> -> UTF-8 String
std::basic_string<wchar_t> -> Blödsinn
std::basic_string<TCHAR> -> Blödsinn
std::basic_string<unsigned long> -> Völliger Blödsinn
std::basic_string<char32_t> -> Theoretisch UTF-32, de facto unnötig.

Und haben wir heute doch garnichts vollbracht,
so haben wir doch wenigstens einen dummen Spruch gebracht.

∞

@Bitte ein Bit: warum sollte basic_string<char> nicht für UTF-8 geeignet sein?

Eigentlich deutet es sich schon bei deinem Namen an. UTF8 hat die Eigenschaft nicht unbedingt immer ein Zeichen mit einem Byte zu kodieren. Nur die ersten 128 Zeichen werden mit einem Byte kodiert. Deutsche Umlaute werden schon beispielsweise mit zwei Byte, fernöstliche Zeichen mit 4 Bytes kodiert.

Würde man nun std::basic_string<char> als UTF8 String interpretieren, bekämen die Funktionen von std::basic_string<> eine andere Bedeutung. Die Funktionen würden nicht mehr auf Zeichen arbeiten, sondern auf Bytes, deren Interpretation immer von den vorhergehenden Byte abhängt.

Mit den Programmen Notepad++ und Hxd kann man das schön nachvollziehen. Teststring: "äüöß€..."

Shade Of Mine

Das Problem bei UTF8 ist nicht die Speicherung der Bytes. Bytes speichern ist trivial.

Sondern das Arbeiten mit den Daten. Wie sortiere ich Strings, wie wandle ich Uppercase/Lowercase etc. um, wie bekomme ich die Anzahl der Buchstaben raus, wie trenne ich den String nach N Zeichen ab, etc.

Und da ist C++ einfach unkomfortabel und java sehr komfortabel.

dot

Sprachen schrieb:

+ einheitliche umfangreiche Standard API ohne dabei zur Bloatware zu werden

Du meinst dieses 150MB Ding, ohne das nichts läuft und das bis vor kurzem noch im Bündel mit Malware vertrieben wurde?

Sprachen schrieb:

+ geringere Fehlerträchtigkeit

Das kann ich leider so nicht unterschreiben, meiner Erfahrung nach ist sogar genau das Gegenteil der Fall. Insbesondere die Garbage Collection ist da ein Dorn im Auge. So lange man keine Ressourcen außer dynamisch erzeugter Objekte benötigt und sich schön weit weg von den Grenzen des verfügbaren RAM aufhält, geht's. Sobald man mit irgendwelchen anderen Ressourcen arbeiten will, macht GC einem das Leben zur Hölle. Das Schreiben von Code, der nicht leaked, ist in Sprachen wie Java und C# leider wahnsinnig schwer. Eine umfangreiche Diskussion zum dem Thema findest du z.B. hier: http://zfx.info/viewtopic.php?f=4&t=2337

Shade Of Mine schrieb:

Das Problem bei UTF8 ist nicht die Speicherung der Bytes. Bytes speichern ist trivial.

Sondern das Arbeiten mit den Daten. Wie sortiere ich Strings, wie wandle ich Uppercase/Lowercase etc. um, wie bekomme ich die Anzahl der Buchstaben raus, wie trenne ich den String nach N Zeichen ab, etc.

Und da ist C++ einfach unkomfortabel und java sehr komfortabel.

Zeig mal, wie das in Java geht.

Bedenke:
- Buchstaben != Codepoint != .length()
- "ß" nach Uppercase wird "SS"
- Sortieren nach UTF-16 ist mühsam

In C++ geht nur sortieren einfach, aber dafür richtig. UTF-8 wird nämlich genau gleich geordnet wir UTF-32.

Shade Of Mine

Was genau davon geht in Java denn nicht automatisch korrekt?

Ich wüsste aber auch nicht warum ich etwas anderes als UTF8 nehmen sollte. Kann gut sein dass es mit den nie verwendeten anderen UTF Varianten wie 16 und 32 oder UCS2 oder was es da sonst noch so gibt, Probleme gibt. Aber UTF8 ist pretty straight forward in Java.

Beispiel: http://ideone.com/4XkRji

http://ideone.com/BNVZNd

reverse gg̈g => g̈gg
Länge: 4
Splitten: ggẍg

wie bekomme ich die Anzahl der Buchstaben raus

fail

wie trenne ich den String nach N Zeichen ab

fail