von Java nach C++

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

Shade Of Mine

OK, ist in Java wohl doch nicht trivial. uU geht es aber wie in C# recht easy per streamreader/streamwriter.

Aber OK, klarer Minuspunkt für Java hier.

Zeus

Shade Of Mine schrieb:

OK, ist in Java wohl doch nicht trivial. uU geht es aber wie in C# recht easy per streamreader/streamwriter.

Aber OK, klarer Minuspunkt für Java hier.

Wenn ich blos den Fehler nur nachvollziehen könnte xD

Shade Of Mine schrieb:

OK, ist in Java wohl doch nicht trivial. uU geht es aber wie in C# recht easy per streamreader/streamwriter.

Kannst du, oder ein anderer, mal dieses Beispiel nach C# übersetzen.

Ok, hab das gefunden. Auch nicht so einfach.
http://stackoverflow.com/questions/228038/best-way-to-reverse-a-string

using System;
using System.Collections.Generic;
using System.Globalization;
using System.Linq;

public static class Test
{
    private static IEnumerable<string> GraphemeClusters(this string s) {
        var enumerator = StringInfo.GetTextElementEnumerator(s);
        while(enumerator.MoveNext()) {
            yield return (string)enumerator.Current;
        }
    }
    private static string ReverseGraphemeClusters(this string s) {
        return string.Join("", s.GraphemeClusters().Reverse().ToArray());
    }

    public static void Main()
    {
        var s = "Les Mise\u0301rables";
        var r = s.ReverseGraphemeClusters();
        Console.WriteLine(r);
    }
}

Sieht so aus, als könne Java kein Unicode. Hier mit Regexen: http://stackoverflow.com/questions/4304928/unicode-equivalents-for-w-and-b-in-java-regular-expressions

Also sieht es in Java genau gleich aus wie in C++:
- Ich will Strings nur weiterleiten/durchsuchen:
- Ich will Strings irgendwie bearbeiten: (ja, es geht "oft", wobei "oft" in Java öfters als in C++ ist, aber fast ist nicht ganz)

Deshalb gibt es ICU auch für Java, weil Java kein Unicode kann. Mal ein anderes Beispiel als Graphemclusters: http://userguide.icu-project.org/boundaryanalysis

Wer Unicode wirklich braucht, und bei mir ist das bisher nicht vorgekommen, der muss sowieso auf externe Bibliotheken zurückgreifen. Und wem es reicht, unicode-aware zu sein, dem reicht auch C++ und std::string.

Ethon

Darf ich fragen was denn die korrekte Vorgehensweise wäre wenn Codepoint != Zeichen?
Ich dachte es wäre in Ordnung alle UTF8-Zeichen zu decodieren, umzudrehen und wieder zu codieren.

Man muss (extended) Graphemcluster erkennen und diese umdrehen: www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries (bzw. http://userguide.icu-project.org/boundaryanalysis)

Deshalb habe ich auch geschrieben, dass UTF8-CPP nichts bringt, weil Codepoints nichtssagend sind. Man kann damit das Encoding konvertieren, aber nicht den String analysieren.

idx schrieb:

Hallo,

ich bin neu hier und starte direkt mal mit einer Frage.

Ich komme aus der Java Welt und würde jetzt gerne mit C++ beginnen - auf kurz oder Lang soll da mal ein größeres Spiele Projekt raus werden.

Ich suche daher ein gute Buch oder Tutorial was nicht bei 0 anfängt, d.h ich habe durchaus Erfahrung mit Programmierung (auch wenn die C Entwickler einen Java Entwicklern gerne belächeln)
Speziell solche Sachen wie Speicherverwaltung, Pointer und Effektiver Code interessieren mich.
Was gibt es so für Standard libs oder Funktionen die jeder kennen sollte?
(Bei Java z.B. dieser ganze Apache Kram - commons oder log4j und solche Sachen)
Was für Stolperfallen gibt es?

Vielen Dank!

Ohne jetzt die 8 Seiten Diskussion gelesen zu haben - ich kann folgende Bücher empfehlen:

Der C++-Programmierer: C++ lernen - Professionell anwenden - Lösungen nutzen von Ulrich Breymann
Effective C++: 55 Specific Ways to Improve Your Programs and Designs von Scott Meyers

knivil

Ich sehe schon, UTF8 ist riesiger Bockmist.

knivil schrieb:

Ich sehe schon, UTF8 ist riesiger Bockmist.

Du laberst Unfug. Mit UTF-16 (wie bei Java und C# verwendet) hast du exakt die gleichen Probleme und noch ein paar mehr. UTF-16 ist ebenfalls ein Variable-Length-Encoding. Bei UTF-8 musst du dich halt bereits bei allen Codepoints größer 0x7F mit beschäftigen, die Wahrscheinlichkeit, dass dein Code getestet ist, steigt also.

Ja, Unicode ist verdammt komplex, wenn man alle Aspekte behandeln will. Und das völlig unabhängig vom Encoding.

dot

Von allen Unicode Encodings, die es im Moment so gibt, ist UTF-8 vermutlich mit Abstand das beste...

Sowohl Java als auch Windows NT verwenden UTF-16 hauptsächlich aus Legacy-Gründen, nicht weil es irgendwelche Vorteile hätte. Als Microsoft damals mit der Implementierung von Unicode begonnen hatte, gab es noch gar kein UTF-8 und Unicode war auf 16 Bit beschränkt. Also entschied man sich für UCS-2, aus damaliger Sicht eine nachvollziehbare Entscheidung.

Dass das Unicode-Konsortium sich einige Zeit darauf entschließt, den Coderaum über 16 Bit hinaus zu erweitern, hat wohl weder Microsoft noch Sun geschmeckt. Jetzt verbindet UTF-16 einfach nur noch die Nachteile von UTF-8 und UCS-4/UTF-32 in einem Format.

dot schrieb:

Von allen Unicode Encodings, die es im Moment so gibt, ist UTF-8 vermutlich mit Abstand das beste...

Unfug, UTF-32 wird von einer modernen CPU wesentlich schneller verarbeitet, als UTF-8, denn UTF-32 hat kein Variable Lengh Coding und das spart Zeit.

UTF-32 ist also schneller, aber man bekommt nichts geschenkt, denn es braucht mehr Speicher.