Warum hat C++ so eine aufwendige Syntax?



  • DEvent schrieb:

    Anders bei Java:

    String x = "a";
    String y = "a";
    x == y; // false
    

    Weil der ==Operator bei Java nicht auf Inhalt sondern auf Identitaet prueft.

    Das stimmt nicht ganz. x und y sind hier identisch, x==y ist true.
    Stichwort Stringpool.

    tfa



  • tfa schrieb:

    ...
    Stichwort Stringpool.

    tfa

    Naja, spätestens bei einem anderen Klassentypen als string (und nennen wir ihn einfach nur MyString) funktioniert das aber auch alles sowieso nicht mehr.

    Gruß,

    Simon2.



  • Simon2 schrieb:

    Da aber Jesters Code fachlich etwas Anderes macht als Mr. N's, ist das kein besonders geglücktes Gegenbeispiel...

    Das siehst Du falschrum. Der Code ist ziemlich stupide von C++ nach Java übersetzt. Und oh wunder, er liefert genau das, was MrN als tolles Feature von C++ angepriesen hat... das sagt nichts über das Gegenbeispiel aus, sondern etwas über das erste Beispiel (und vielleicht auch über den Autor des ersten Beispiels ;)).



  • Jester schrieb:

    ...Der Code ist ziemlich stupide von C++ nach Java übersetzt. Und oh wunder, er liefert genau das, was MrN als tolles Feature von C++ angepriesen hat... das sagt nichts über das Gegenbeispiel aus, sondern etwas über das erste Beispiel (und vielleicht auch über den Autor des ersten Beispiels ;)).

    Ich habe das schon so verstanden 😃 ... hatte aber den Eindruck, dass hier eine Diskussion unter Leuten ausbricht, die das nicht verstanden haben und deswegen Deinen Code eben als "Gegenbeispiel" und nicht als Beleg für einen didaktischen faux-pas von Mr N. interpretierten.

    Gruß,

    Simon2.



  • Jester schrieb:

    Simon2 schrieb:

    Da aber Jesters Code fachlich etwas Anderes macht als Mr. N's, ist das kein besonders geglücktes Gegenbeispiel...

    Das siehst Du falschrum. Der Code ist ziemlich stupide von C++ nach Java übersetzt. Und oh wunder, er liefert genau das, was MrN als tolles Feature von C++ angepriesen hat... das sagt nichts über das Gegenbeispiel aus, sondern etwas über das erste Beispiel (und vielleicht auch über den Autor des ersten Beispiels ;)).

    Und daß du durch die sture Übersetzung eine völlig andere Semantik erzeugst, geht bei den Beispielen leider unter. Ändern wir mal die C++-Version etwas ab, um den Sachverhalt zu verdeutlichen:

    string s1 = "x";
    string s2;s2.push_back('x');//statt des push_back() könnte auch eine Nutzer-Eingabe hier stehen
    if(s1==s2)
      cout<<"gleich";
    

    hääää schrieb:

    wär is päle dofg 😮 😕 😕 👎 👎

    die x-te Reinkarnation eines ***** (ich bin nicht ganz sicher, wie die erste Inkarnation hieß, die (x+1)-te ist Undertaker (mit einer Sicherheit von 99,9%)).



  • hääää schrieb:

    wär is päle dofg 😮 😕 😕 👎 👎

    Das ist so ein Typ, der nach jeder Blamage hier wieder mit einem neuen Nickname im Forum auftaucht. Und immer wieder die gleichen Threads startet und versucht es immer wieder. Anscheinend ist er ein bischen *mach_eine_deutliche_handbewegung*

    pale dog -> vista -> undertaker

    und hier lassen sich alle immer wieder verarschen. 😞



  • CStoll schrieb:

    Und daß du durch die sture Übersetzung eine völlig andere Semantik erzeugst, geht bei den Beispielen leider unter.

    Du hast scheinbar immer noch nicht verstanden, worum es mir ging. Aber macht nix. Ich kann damit leben.



  • Jester schrieb:

    Mr. N schrieb:

    std::string a = "x", b = "x";
    a==b; //true
    

    🙂

    Na, der war mal wieder mit Anlauf. 😃

    String a = "x";
        String b = "x";
        if(a==b) System.out.println("a==b");
        else System.out.println("a!=b");
    

    magst Du das mal ausprobieren?

    Das untermauert übrigens auch weiter Deine Aussage, dass Du auch diese J-Geschichte bestens beurteilen kannst. 😃

    Und es belegt wunderbar, wieso ich dich immer als "böser Jester" begrüße. 🙂

    Darf man sich wirklich auf String-Pools verlassen? Auch bei sowas?

    String a = "1";
    Integer b = new Integer(1);
    a == b.toString(); //true??
    

    In welcher Java-Version haben sie das eingeführt? Wozu gibts dann equals überhaupt?



  • Mr. N schrieb:

    ...
    In welcher Java-Version haben sie das eingeführt? Wozu gibts dann equals überhaupt?

    Eigentlich bin ich nicht Jesters Anwalt, aber bedenke doch mal Folgendes:
    Wenn Dein ursprüngliches Beispiel gelautet hätte:

    MrN::string a = "x", b = "x";
    a==b; //true
    

    hättest Du Deinen Punkt ebensogut rübergebracht aber die letzten 3 Seiten Diskussion gespart. 😃

    Ich denke, mehr wollte Jester nicht ausdrücken....

    Gruß,

    Simon2.



  • String-Pools, k.a. letztens als ich 2 Strings mit == vergleichen wollte, ging es gruendlich schief.

    Btw, ich fuer meinen Teil weis dass man nicht einfach eine Zeile aus Sprache X waehlen kann und sie Woertlich mit einer Zeile aus Sprache Y vergleichen kann. C++ macht es so, Java macht es anders, Sprache Blub macht was ganz komisches. Am Ende zaehlt doch nur das man damit Programme schreiben kann.

    Aber C++ ist wirklich ein wenig gefrickel mit den includes und den Libs und den Makefiles. Wann wird das so elegant wie bei Java, C# oder Ruby geloest? Einfach ein import packet.Klasse; und noch in classpath angeben wo sich die Libs befinden.



  • Wegen der C++ Syntax gibt es auch keine richtigen Garbagecollector, weil das zu schierig ist.



  • Simon2 schrieb:

    Ich denke, mehr wollte Jester nicht ausdrücken....

    Ich weiß zwar nicht was du meinst, aber lassen wir das doch Jester selber sagen. Es interessiert mich auch, wie die String-Pool-Garantien sind, und wieso ich die nicht in der Dokumentation von java.lang.String finde. 😕

    DEvent schrieb:

    Aber C++ ist wirklich ein wenig gefrickel mit den includes und den Libs und den Makefiles. Wann wird das so elegant wie bei Java, C# oder Ruby geloest? Einfach ein import packet.Klasse; und noch in classpath angeben wo sich die Libs befinden.

    Da gab es einen Vorschlag für C++0x, der wurde aber glaube ich abgelehnt. (Modules)



  • Hamselt schrieb:

    Wegen der C++ Syntax gibt es auch keine richtigen Garbagecollector, weil das zu schierig ist.

    natürlich gibt es für c++ garbagecollectors. die funktionieren auch gut, nur sind sie halt nicht übermäßig beliebt.



  • DEvent schrieb:

    String-Pools, k.a. letztens als ich 2 Strings mit == vergleichen wollte, ging es gruendlich schief.

    Als ich von C++ nach Java gewechselt bin, war es das erste was bei mir in die Hose ging. Kollege von mir "Mach mal dies und das bitte zu morgen fertig.". Ich am basteln mit Strings, ich natürlich ganz selbstverständlich zwei Strings mit == verglichen. "Hem, also irgendwie hab ich hier nen Fehler. Woran liegt das?" Kollege: "Zeig mal! Achso... neee, du darfst in Java da kein == benutzen. Mußt du equals benutzen."

    Yo, das weiß ich noch wie heute. Und das ist schon 7 Jahre her!

    DEvent schrieb:

    Aber C++ ist wirklich ein wenig gefrickel mit den includes und den Libs und den Makefiles. Wann wird das so elegant wie bei Java, C# oder Ruby geloest? Einfach ein import packet.Klasse; und noch in classpath angeben wo sich die Libs befinden.

    Yo, wer den offenen ISO-C++-Prozess aufmerksam und interessiert verfolgt, wird die Antwort darauf kennen. :p



  • DEvent schrieb:

    ...Einfach ein import packet.Klasse; und noch in classpath angeben wo sich die Libs befinden.

    Äh ? Wo liegt da denn der Unterschied zu #include <subDir/header.h> (gerade, wo der headername in 99% der Fälle der Klassenname ist) und der Angabe eines Includepfads ?
    Dass ich in C++ statisch linken kann und dann schon vor der Laufzeit einen LibPfad brauche ?

    Gruß,

    Simon2.



  • Hamselt schrieb:

    Wegen der C++ Syntax gibt es auch keine richtigen Garbagecollector, weil das zu schierig ist.

    Aha? Aber das GC im nächsten C++ Standard enthalten sein wird, ist dir entgangen?



  • CStoll schrieb:

    wie man in Java const-korrekte Programme schreiben kann

    Genau das wollte ich gleich im Java-Forum fragen 🙂

    "Stringpool" war das Wort, was ich hier gesucht hatte:

    KasF schrieb:

    Da "x" sonst irgendwo im Speicher erzeugt werden würde und a und b beide diese Speicherstelle von "x" refernzieren würden.



  • Mr. N schrieb:

    Simon2 schrieb:

    Ich denke, mehr wollte Jester nicht ausdrücken....

    Ich weiß zwar nicht was du meinst, ...

    Wenn Du nicht verstehst, was ICH meine, darfst Du ruhig mich fragen (zumal ich in diesem Fall Jesters Meinung teile): Dein Beispiel war ungeschickt !
    Nicht mehr und nicht weniger: Du hattest einen richtigen Punkt, hast aber ein Beispiel gewählt, in dem dieser Punkt nicht ausreichend (klar) herauskommt.

    Gruß,

    Simon2.



  • Mr. N schrieb:

    DEvent schrieb:

    Aber C++ ist wirklich ein wenig gefrickel mit den includes und den Libs und den Makefiles. Wann wird das so elegant wie bei Java, C# oder Ruby geloest? Einfach ein import packet.Klasse; und noch in classpath angeben wo sich die Libs befinden.

    Da gab es einen Vorschlag für C++0x, der wurde aber glaube ich abgelehnt. (Modules)

    Ne, nicht wirklich. Wurde nicht abgelehnt. Wird nur nicht mehr Thema für den C++0x sein, weil man das alles sonst zeitlich nicht mehr schaffen würde. (gibt wichtigeres für C++0x fertig zu machen)

    Wird für den darauf folgenden Standard ein Thema sein, der Proposal wurde sozusagen auf Wait gesetzt. 😉



  • Artchi schrieb:

    DEvent schrieb:

    String-Pools, k.a. letztens als ich 2 Strings mit == vergleichen wollte, ging es gruendlich schief.

    Als ich von C++ nach Java gewechselt bin, war es das erste was bei mir in die Hose ging. Kollege von mir "Mach mal dies und das bitte zu morgen fertig.". Ich am basteln mit Strings, ich natürlich ganz selbstverständlich zwei Strings mit == verglichen. "Hem, also irgendwie hab ich hier nen Fehler. Woran liegt das?" Kollege: "Zeig mal! Achso... neee, du darfst in Java da kein == benutzen. Mußt du equals benutzen."

    Falls es dich beruhigt, sowas passiert nicht nur in Java (Stichwort strcmp()).

    @KasF: Die Frage nach der const correctness hatte ich schon bei einem der letzten C++ vs. Java Threads aufgebracht - mit dem Ergebnis, daß man ja die Klasse aufteilen könnte in eine änderbare Klasse und ein nicht-änderbares Interface (was dem const entsprechen sollte). Weitergehende Fragen zu der Umsetzung wurden von den Java-Verteidigern ignoriert,
    (ich vermute mal, weil sie selber keine Ahnung haben, wie man das umsetzen könnte)


Anmelden zum Antworten