Ist C++ noch zu retten?



  • @Steffo sagte in Ist C++ noch zu retten?:

    @manni66 Tolle, inhaltliche Antwort! Hast du dir mal CppCon-Vorträge angeschaut? Da gibt es auch jede Menge Beiträge, die C++ kritisieren.

    Wenn man zu Rust wechseln will, erübrigt sich das.


  • Gesperrt

    Dieser Beitrag wurde gelöscht!


  • @Bashar sagte in Ist C++ noch zu retten?:

    Membervariablen haben in C++ eine festgelegte Initialisierungsreihenfolge, nämlich so wie deklariert. Wenn man dich Code Reviews machen lässt, solltest du das doch eigentlich wissen. Das ist z.B. bei Konstruktorinitialisiererlisten wichtig, dass die eben nicht in der Reihenfolge abgearbeitet werden, wie sie dastehen -- beliebter Anfängerfehler.

    Der Punkt ist, weshalb ist es in C++ nicht generell ein Error, wenn die Reihenfolge nicht stimmt? Die Compiler liefern aber nur Warnings, und das meistens nur, wenn man entsprechende Flags beim Übersetzen anführt. Entweder die Norm erlaubt eine wahlfreie Initialisierung (technisch wäre das trotz Exceptions möglich – nur entsprechend aufwendiger) oder es gibt einen Error. Stattdessen eiert man in C++ herum und kann sich nicht entscheiden was man will. Die meiner Meinung nach schlechteste der möglichen Lösungen.



  • Ich finde es etwas übertrieben, eine ganze Sprache zu verteufeln, weil ein Feature etwas kurios ist.
    C++ kann viele Dinge, aber wie das ebenso mit mächtigen Werkzeugen ist, gibt es auch ein paar Fallen.

    Mit einer Waffe kann man auch ganz normal im Sportverein trainieren aber man kann auch versehentlich den Kollegen bei der Jagd übern Haufen schießen.

    Klar kannst du auf eine andere Sprache wechseln, aber da wird garantiert auch ein Moment kommen wo du dir denkst:
    "Mit C++ hätte ich das eleganter lösen können."



  • @john-0 sagte in Ist C++ noch zu retten?:

    @Bashar sagte in Ist C++ noch zu retten?:

    Konstruktorinitialisiererlisten wichtig

    Der Punkt ist, weshalb ist es in C++ nicht generell ein Error, wenn die Reihenfolge nicht stimmt?

    Tja, gute Frage, die man vielleicht Bjarne Stroustrup stellen müsste. Vielleicht hat er in Design&Evolution etwas dazu gesagt.

    Die meiner Meinung nach schlechteste der möglichen Lösungen.

    Ja, denke ich auch. Aber man kann nicht einfach in einem neuen Standard Code als falsch deklarieren, der Jahrzehnte funktioniert hat.

    Edit: Hier steht was zur Geschichte davon: https://www.usenix.org/legacy/publications/compsystems/1989/sum_stroustrup.pdf

    The syntax for initializing base classes and members has been extended to cope with multiple inheritance and the order of initialization has been more precisely defined. Leaving the initialization order unspecified in the original definition of C++ gave an unnecessary degree of freedom to language implementers at the expense of the users. In most cases, the order of initialization of members doesn't matter and in most cases where it does matter, the order dependency is an indication of bad design. In a few cases, however, the programmer absolutely needs control of the order of initialization.



  • @Steffo: Was für einen C++ Compiler hast du denn, daß da bei falscher Initialisierungsreihenfolge kein Fehler erscheint?
    Ideone-Code: gcc 8.3 (C++14)

    Zumindestens ab gcc 8.1 (neueste ist 10.1) kommt eine eindeutige Fehlermeldung,:

    <source>:5:23: error: designator order for field 'test()::A::x' does not match declaration order in 'test()::A'
         A a{.y = 2, .x = 1}; // error; designator order does not match declaration order
    

    Vorher (mit mindestens -std=c++11 als Compiler-Option):

    <source>:5:23: sorry, unimplemented: non-trivial designated initializers not supported
        A a{.y = 2, .x = 1}; // error; designator order does not match declaration order
    

    Kann man z.B. mit Compiler Explorer (godbolt) testen.
    (da es nicht kompiliert, kann ich keinen direkten Link setzen ;- )

    Edit: Und auch der msvc (ab v19.21) liefert eine identische Fehlermeldung (mit /std:c++latest):

    <source>(5): error C7560: 'x': designators must appear in member declaration order of class 'test::A'
    

    Davor kommen Syntaxfehler bzgl. des Punktes:

    <source>(5): error C2059: syntax error: '.'
    ...



  • @Bashar sagte in Ist C++ noch zu retten?:

    The syntax for initializing base classes and members has been extended to cope with multiple inheritance and the order of initialization has been more precisely defined. Leaving the initialization order unspecified in the original definition of C++ gave an unnecessary degree of freedom to language implementers at the expense of the users. In most cases, the order of initialization of members doesn't matter and in most cases where it does matter, the order dependency is an indication of bad design. In a few cases, however, the programmer absolutely needs control of the order of initialization.

    Das ist ein Plädoyer dafür die Reihenfolge gar nicht vorzuschreiben, weil nur so der Entwickler die Reihenfolge festlegen kann (indirekt macht er das ja über die Reihenfolge der Definition). Grundsätzlich hätte man vieles beim Übergang von Stroustrup C++ zu ISO C++ genauer definieren können, wenn man das gewollt hätte. Das Problem bei C und noch mehr bei C++ ist, dass die unterschiedlichen Hersteller einfach nicht wollen, dass bestimmte Sprachaspekte exakt definiert sind, weil sie das einschränkt. Das ist zum Nachteil der Nutzer der Sprache.



  • @john-0 sagte in Ist C++ noch zu retten?:

    @Bashar sagte in Ist C++ noch zu retten?:

    The syntax for initializing base classes and members has been extended to cope with multiple inheritance and the order of initialization has been more precisely defined. Leaving the initialization order unspecified in the original definition of C++ gave an unnecessary degree of freedom to language implementers at the expense of the users. In most cases, the order of initialization of members doesn't matter and in most cases where it does matter, the order dependency is an indication of bad design. In a few cases, however, the programmer absolutely needs control of the order of initialization.

    Das ist ein Plädoyer dafür die Reihenfolge gar nicht vorzuschreiben, weil nur so der Entwickler die Reihenfolge festlegen kann

    Das ist kein Plädoyer. Vielleicht solltest du dem Link folgen. Mein Auszug soll nur die geschichtliche Einordnung liefern und damit die Frage beantworten, warum die Reihenfolge der Member-Initialisierer von der tatsächlichen Initialisierungsreihenfolge abweichen darf.

    Grundsätzlich hätte man vieles beim Übergang von Stroustrup C++ zu ISO C++ genauer definieren können, wenn man das gewollt hätte.

    Der größte Nachteil von C++ ist die Rückwärtskompatibilität. Gleichzeitig ist das aber auch der größte Vorteil. Damit müssen wir wohl leben.



  • @Th69 Wir verwenden hier gcc 7.5 und frag mich nicht, was alles aktiviert wurde, damit das kompiliert.
    Es ist jedenfalls begrüßenswert, dass nun zur Compile-Zeit ein Fehler geworfen wird! 🙂


  • Gesperrt

    Dieser Beitrag wurde gelöscht!


  • @Bashar sagte in Ist C++ noch zu retten?:

    Das ist kein Plädoyer. Vielleicht solltest du dem Link folgen.

    Ich habe das Buch aus dem Regal genommen, und es darin nachgelesen.

    Mein Auszug soll nur die geschichtliche Einordnung liefern und damit die Frage beantworten, warum die Reihenfolge der Member-Initialisierer von der tatsächlichen Initialisierungsreihenfolge abweichen darf.

    Das dürfte noch wesentlich älter sein, weil es ja einmal so etwas wie C with Classes gab. Exceptions kamen erst deutlich später, so dass am Anfang die Reihenfolge wohl herzlich egal war. Aber was Stroustrup schreibt, geht ja noch über das hier angesprochene hinaus. Er spricht die Frage an, ob der Hersteller eine Compilerspezifische Reihenfolge definieren darf, die ubabhängig von der Reihenfolge der Definition im Programmcode ist. Das ist etwas anderes als wenn man in der Definition des Constructors eine andere Reihenfolge als in der Klassendefinition als Programmierer definiert.

    Der größte Nachteil von C++ ist die Rückwärtskompatibilität. Gleichzeitig ist das aber auch der größte Vorteil. Damit müssen wir wohl leben.

    Würde man das wahlfrei (für den Nutzer nicht den Compilerhersteller) machen, würde es kein Problem geben.



  • @titan99_ sagte in Ist C++ noch zu retten?:

    Nein. Wenn der Code lauffähig bleibt bitte keinen Kompilierfehler ausgeben und die Applikation nicht fertig erstellen, dann reicht eine Warnung.

    Programme mit UB sind lauffähig, und weil sie das sind gibt es doch so viel Ärger mit C++ Programmen. Entweder der Compiler findet hier Potential für UB, dann hat er den Übersetzungsvorgang abzubrechen, oder er findet das nicht und dann braucht es auch keinen Warnung mehr.



  • @john-0 Aber es ist ja kein UB. Die Initialisierungsreihenfolge ist klar definiert. Wenn ich die Zuweisung in der Initialisierungsliste im Konstruktor anders hinschreibe ist das immer noch definiert. Problematisch kann das nur werden, wenn ich ein Member habe, der von anderen Membern abhängig ist, welche ich vorher initialisiert haben muss und da bei der Definition nicht aufgepasst habe.

    Wenn man von vorner herein gezwungen wäre, dass in der gleichen Reihenfolge zu machen, gäbe es wohl eine Fehlerquelle weniger, aber jetzt würde ich das auch nicht mehr ändern wollen, sondern Rückwertskompatibiltät gewährleisten. Aber ein Warning ist schon in Ordnung, welches einem mitteilt, dass man sich damit selbst reinlegen kann.



  • @Schlangenmensch sagte in Ist C++ noch zu retten?:

    Problematisch kann das nur werden, wenn ich ein Member habe, der von anderen Membern abhängig ist, welche ich vorher initialisiert haben muss und da bei der Definition nicht aufgepasst habe.

    Und wie nennst Du das?


  • Mod

    @john-0 sagte in Ist C++ noch zu retten?:

    @Schlangenmensch sagte in Ist C++ noch zu retten?:

    Problematisch kann das nur werden, wenn ich ein Member habe, der von anderen Membern abhängig ist, welche ich vorher initialisiert haben muss und da bei der Definition nicht aufgepasst habe.

    Und wie nennst Du das?

    "Fehler" nennt man das. Aber nicht jeder Fehler ist UB.



  • @SeppJ sagte in Ist C++ noch zu retten?:

    "Fehler" nennt man das. Aber nicht jeder Fehler ist UB.

    Das habe ich (mal wieder) nicht behauptet. Hier (in dem Beispiel von Schlangenmensch) wird aber auf etwas nicht Initialisiertes zugegriffen, und das ist klassisches UB.


  • Mod

    @john-0 sagte in Ist C++ noch zu retten?:

    @SeppJ sagte in Ist C++ noch zu retten?:

    "Fehler" nennt man das. Aber nicht jeder Fehler ist UB.

    Das habe ich (mal wieder) nicht behauptet.

    Offtopic: Wenn man dich dauernd missversteht, kommunizierst du vielleicht schlecht...



  • @john-0 Der Fehler führt zu UB, aber deshalb ist doch noch lange nicht jede "falsche" Reihenfolge UB...



  • @SeppJ sagte in Ist C++ noch zu retten?:

    Offtopic: Wenn man dich dauernd missversteht, kommunizierst du vielleicht schlecht...

    Ernsthaft? Der Kontext war eindeutig, und wenn Du Dir die Beiträge aufmerksam durchgelesen hättest, hättest Du selbst gesehen, dass der Zugriff auf etwas Nichtinitialisiertes UB ist, und nicht nur ein „Fehler“.



  • @Schlangenmensch sagte in Ist C++ noch zu retten?:

    @john-0 Der Fehler führt zu UB, aber deshalb ist doch noch lange nicht jede "falsche" Reihenfolge UB...

    Wo schrieb ich das?

    Ich schrieb von Potential für UB, d.h. es tritt nur unter bestimmten Randbedingungen auf. Und als Antwort auf Titan99 schrieb ich, dass Programme mit UB lauffähig sind. D.h. Lauffähigkeit ist keinerlei Qualitätszeichen.


Anmelden zum Antworten