von Java nach C++

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

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.