von Java nach C++



  • SoGehtEs schrieb:

    9. Strings sind ein Graus in C++. Ich kann dir nicht wirklich einen guten empfehlen, wer std::string sagt, hat keine Ahnung von Internationalisierung.

    Hmm. Was hat i18n mit dem verwendeten String-Datentypen zu tun? Ein std::string ist eine Kette von Bytes und damit eine Low-Level-Struktur. Was ich damit letztendlich anstelle, ist mir überlassen.

    Warum sollte ich nicht auf Basis von std::string eine ordentliche Internationalisierungsinfrastruktur aufbauen können?

    Finde die Frage gerade recht interessant. Wenn nötig, kann ein Mod das auch gerne in einen anderen Thread splitten.



  • Zur Javadoc-Diskussion:

    Äußerst gelungen finde ich hier Godoc, das Dokumentationssystem der Programmiersprache Go. Es erstellt eine IMHO sehr gut lesbare Doku (im Gegensatz zu so manchem was ich schon von Javadoc gesehen habe) ohne dass man seinen Quellcode mit aufdringlichen Annotationen in einem bestimmten Format verschandeln muss.

    Genutzt werden einfach an der richtigen Stelle plazierte Kommentare. Ausspucken kann es HTML (als Datei oder auf einem lokalen Webserver serviert), aber ist flexibel genug auch ein ernsthaft nutzbares Commandline-Tool zu füttern.

    Die generierte HTML-Doku enthält Links, die einem bei Bedarf auch direkt die richtige Stelle des Quellcodes zeigen.

    Beispiel
    http://golang.org/pkg/os/
    (für das Aussehen im Quellcode sind unten auch die Dateien des Packages aufgelistet; oder halt einfach auf einen Funktionsnamen klicken)

    Die komplette golang.org-Website läuft auf dem Godoc-Webserver, d.h. man kann auch zusätzlichen Content elegant in die Doku einbauen.



  • SoGehtEs schrieb:

    9. Strings sind ein Graus in C++. Ich kann dir nicht wirklich einen guten empfehlen, wer std::string sagt, hat keine Ahnung von Internationalisierung.

    Inwiefern sind Strings in Java denn besser?



  • badgerbadgerbadger schrieb:

    SoGehtEs schrieb:

    9. Strings sind ein Graus in C++. Ich kann dir nicht wirklich einen guten empfehlen, wer std::string sagt, hat keine Ahnung von Internationalisierung.

    Hmm. Was hat i18n mit dem verwendeten String-Datentypen zu tun? Ein std::string ist eine Kette von Bytes und damit eine Low-Level-Struktur. Was ich damit letztendlich anstelle, ist mir überlassen.

    Wer das glaubt kann auch einen std::vector nehmen. Woher weißt du viele Zeichen (nicht bytes) dein String hat, wenn du nur einen Haufen von Bytes ohne angabe des Encodings hast?

    dot schrieb:

    SoGehtEs schrieb:

    9. Strings sind ein Graus in C++. Ich kann dir nicht wirklich einen guten empfehlen, wer std::string sagt, hat keine Ahnung von Internationalisierung.

    Inwiefern sind Strings in Java denn besser?

    Keine Ahnung was die genau machen, ich arbeite schon ewig nich tmehr mit Java, aber immerhin gibts da einen String den (fast) jede Library verwendet und man muss nicht ständig konvertieren wie in 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?

    Was nützt es mir, das zu wissen?
    Encoding ist in (modernem) C++ immer UTF-8, nicht der UTF-16-Schrott.

    Und Java mit seinem meinStringMitLangemNamen.codePointCount(0, meinStringMitLangemNamen.length()) ist da auch nicht viel besser.

    SoGehtEs schrieb:

    immerhin gibts da einen String den (fast) jede Library verwendet und man muss nicht ständig konvertieren wie in C++.

    Für GUIs ist C++ vielleicht nicht die geeignetste Sprache (Java aber auch nicht). Im Backend kann std::string aber konsistent verwendet werden.



  • htgsdf schrieb:

    Encoding ist in (modernem) C++ immer UTF-8

    Hast du mal ein paar Links zu Opensource Code der utf-8 und std::string verwendet?



  • SoGehtEs schrieb:

    dot schrieb:

    SoGehtEs schrieb:

    9. Strings sind ein Graus in C++. Ich kann dir nicht wirklich einen guten empfehlen, wer std::string sagt, hat keine Ahnung von Internationalisierung.

    Inwiefern sind Strings in Java denn besser?

    Keine Ahnung was die genau machen, ich arbeite schon ewig nich tmehr mit Java, aber immerhin gibts da einen String den (fast) jede Library verwendet und man muss nicht ständig konvertieren wie in C++.

    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!?



  • Das Template std::basic_string kann man schön instanziieren:

    std::basic_string<char> -> ASCII String
    std::basic_string<wchar_t> -> Windows Unicode String
    std::basic_string<TCHAR> -> Variabler String für Windows. Unicode Projekt -> Unicode String, ASCII Projekt -> ASCII String
    std::basic_string<unsigned long> -> UTF32 String
    ...

    Nur für UTF8 ist std::basic_string nicht geeignet, was man dem std::basic_string aber nicht ankreiden kann.



  • seit wann? schrieb:

    htgsdf schrieb:

    Encoding ist in (modernem) C++ immer UTF-8

    Hast du mal ein paar Links zu Opensource Code der utf-8 und std::string verwendet?

    Hier mal ein Programm, das sehr viel mit Textverarbeitung zu tun hat: GNU Source-highlight
    http://git.savannah.gnu.org/cgit/src-highlite.git/tree/src/source-highlight.cc

    @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.



  • Bitte ein Bit schrieb:

    Nur für UTF8 ist std::basic_string nicht geeignet, was man dem std::basic_string aber nicht ankreiden kann.

    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...



  • 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?



  • 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?



  • 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.



  • 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.





  • 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?



  • 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...


Anmelden zum Antworten