Ist C++ noch zu retten?



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



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

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

    Welches Buch? Den Jahresband von Computing Systems 1989? Was du so im Regal hast... es war jedenfalls kein Zitat aus D&E.

    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.

    Nicht wirklich, diese Frage ist da schon längst geklärt.

    Das ist etwas anderes als wenn man in der Definition des Constructors eine andere Reihenfolge als in der Klassendefinition als Programmierer definiert.

    Wenn die Reihenfolge unspezifiziert ist, darf man sich nicht auf eine bestimmte Reihenfolge verlassen und die Initialisierung eines Members nicht von einem anderen abhängig machen. Dann ist die Reihenfolge, in der man die Initialisierer angibt, auch egal.

    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.

    Vielleicht. Andererseits gibt es Warnungen und damit auch die Möglichkeiten, Warnungen ernstzunehmen (z.B. sie wie Fehler behandeln zu lassen.)



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

    D.h. Lauffähigkeit ist keinerlei Qualitätszeichen.

    Die Möglichkeit Warnungen als Fehler zu behandeln gibt es ja z.B
    https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level und wird auch empfohlen. Ist aber freiwillig.



  • generell sind Warnungen auch nicht standardmäßig komplett aktiviert. Auch -Wall aktiviert nicht alle Warnungen.
    Ich persönlich fahre mit diesen Warnings:
    -Wall
    -Wextra
    -Winit-self
    -Wzero-as-null-pointer-constant
    -Wmissing-include-dirs
    -Wredundant-decls
    -Wunreachable-code
    -Wshadow
    -Wcast-align
    -Wswitch-default

    Mal als Beispiel. Die Liste ist ein Kompromiss zwischen "maximaler Nervigkeit" und "Maximaler Sicherheit" mit dem ich ganz gut fahre.



  • @john-0 Und ich sagte, dass es in dem Fall UB nur in speziellen Situationen gibt und das es nicht generell zu UB führt. Und ich daher mit "kein Fehler, aber Warning" vollkommen zu frieden bin. Potential für UB gäbe es ja auch, wenn man die Reihenfolge aus in der Initializer Liste nimmt, oder die gleiche Reihenfolge verpflichtend macht. Man sieht's dann vlt nur schneller. So, jetzt haben wir genug aneinander vorbei geredet 😉



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

    Und ich daher mit "kein Fehler, aber Warning" vollkommen zu frieden bin.

    Das ist genau der Punkt.
    Wer sich nicht 100% mit den Details von C++ auskennt, nimmt bei folgendem Code an, dass erst b, dann a initialisiert wird. Und ich sehe keinen Grund, warum das erlaubt sein sollte. Es kann nur zu Fehlern führen - und führt auch zu Fehlern. Auch Rückwärtskompatibilität ist hier fraglich, weil das eben nur fehleranfälligen Code betreffen würde und einfach zu beheben ist. Oder habe ich was übersehen? Warum nur eine Warnung hier? Ich verstehe nicht, warum man hier mit einer Warnung zufrieden sein kann.

    struct Class1 { int a; };
    
    struct S {
        Class1 a;
        Class1 b;
    
        S() :
            b{1}, 
            a{2 * b.a}
        { }
    };
    
    int main() {}
    


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

    Auch Rückwärtskompatibilität ist hier fraglich, weil das eben nur fehleranfälligen Code betreffen würde und einfach zu beheben ist.

    Dann kriegst du auf einmal 25 Jahre alten Code auf den Tisch, an den sich nur noch einer erinnert, der gerade lieber seinen Ruhestand auf den Bahamas genießen würde. Für ein Nicht-Problem.



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

    Für ein Nicht-Problem.

    Das stimmt einfach nicht. Das ist sogar ein mehrfaches Problem:

    1. du treibst potentielle Entwickler von C++ weg - weil niemand Überraschungen mag. Stell dir Studenten in einem naturwissenschaftlichen Bereich vor, die C++ machen, weil das Framework in C++ ist. Somit ist es häufig die erste Programmiersprache, die gelernt wird. Sehr sehr viele Stunden Fehlersuche werden dadurch verursacht, dass dies nur eine Warnung ist (man sollte Warnung ernst nehmen, bla bla bla, das ist schön und gut, passiert aber eben nicht immer)
    2. der Code war auch möglicherweise auch vor 25 Jahren falsch. Mein Beispiel ist UB. Toll, der Bug soll bleiben, weil er immer da war?
    3. Man hätte ja einführen können, dass das ab C++11, 17, 20, oder was auch immer ein Fehler ist. Den 25 Jahre alten Code könntest du immer noch mit C++98 (wenn überhaupt) übersetzen.

    Aus diesen Gründen stimme ich dir nicht zu.



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

    Und ich sehe keinen Grund, warum das erlaubt sein sollte.

    Als Grund naheliegend ist z.B. wenn die Reihenfolge der Initialisierung keine Rolle spielt. Mein intuitives Verständnis sagt mir, dass dies möglicherweise meistens der Fall ist.

    Irgendwann will man fertig werden und dann ist nicht jede Warnung so wichtig, da immer Zeit verloren geht. Manchmal ist es ein Abwägen zwischen z.B. 20 Minuten denken oder 20 Minuten tippen.



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

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

    Für ein Nicht-Problem.

    Das stimmt einfach nicht. Das ist sogar ein mehrfaches Problem:

    1. du treibst potentielle Entwickler von C++ weg - weil niemand Überraschungen mag. Stell dir Studenten in einem naturwissenschaftlichen Bereich vor, die C++ machen, weil das Framework in C++ ist. Somit ist es häufig die erste Programmiersprache, die gelernt wird. Sehr sehr viele Stunden Fehlersuche werden dadurch verursacht, dass dies nur eine Warnung ist (man sollte Warnung ernst nehmen, bla bla bla, das ist schön und gut, passiert aber eben nicht immer)

    Auch ein Nicht-Problem. Was wollen die alle mit C++? Es gibt soviele andere Programmiersprachen. C++ ist schwer, und es ist erstaunlich, wieviele junge Entwickler trotzdem meinen C++ machen zu müssen. Guck dich doch hier im Forum um ... einer will Webseiten mit C++ auslesen, einer will seine Lagerverwaltung mit C++ machen... es herrscht kein Mangel.

    1. der Code war auch möglicherweise auch vor 25 Jahren falsch. Mein Beispiel ist UB. Toll, der Bug soll bleiben, weil er immer da war?

    Da hatte man 25 Jahre Zeit, die Warnung zu beachten.

    Mir geht es hier aber nicht um den Fall, in dem da tatsächlich ein Bug drin ist, sondern um die sehr viel häufigeren Fälle, in denen es keinen Unterschied macht, die man alle anpassen müsste.

    1. Man hätte ja einführen können, dass das ab C++11, 17, 20, oder was auch immer ein Fehler ist. Den 25 Jahre alten Code könntest du immer noch mit C++98 (wenn überhaupt) übersetzen.

    Wieso ist das Punkt 3 in einem vermeintlichen Argument, dass das ein "mehrfaches Problem" sei? Das ist ein Lösungsvorschlag, und der naheliegendste überhaupt. Natürlich würde ein Verbot sich nur auf einen Standard und alle folgenden auswirken, man kann ja nicht rückwirkend C++98 ändern.



  • Also bei Aggregate-Initializers ist es wohl vom Standard vorgeschrieben dass die Reihenfolge passt. Damit ist jedes Programm "malformed" welches so eine Liste mit falscher Reihenfolge enthält, und jedes "malformed" hat IIRC automatisch UB. Also laut Standard. Laut Compiler wird sich der einfach weigern das zeug überhaupt zu compilieren. Und wenn man es ihm mir irgendwelchen Switches einreden kann es trotzdem zu compilieren, dann wird es dort effektiv sicher auch kein UB geben.
    Strang laut Standard müsste es mMn. aber UB sein.

    @Steffo
    Wenn ihr haufenweise Warnings abdreht bzw. die üblichen -Wall -Wextra nicht aufdreht, dann ... selbst schuld würde ich sagen.



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

    Welches Buch? Den Jahresband von Computing Systems 1989? Was du so im Regal hast... es war jedenfalls kein Zitat aus D&E.

    Dieser Abschnitt (konkret 12.9) findet sich auch im Buch „The Design and Evolution of C++“.

    Nicht wirklich, diese Frage ist da schon längst geklärt.

    Das Buch ist ein Rückblick auf die C++ Entwicklung bis zur ersten ISO Norm. Mit der Norm ist es dann geklärt gewesen. Aber mit Sicherheit nicht beim Erscheinen der ersten Cfront Version.

    Wenn die Reihenfolge unspezifiziert ist, darf man sich nicht auf eine bestimmte Reihenfolge verlassen und die Initialisierung eines Members nicht von einem anderen abhängig machen. Dann ist die Reihenfolge, in der man die Initialisierer angibt, auch egal.

    Das sind zwei Aspekte. Wenn die Reihenfolge unspezifiziert ist, gäbe es zwei Möglichkeiten: man dürfte
    a) in beliebiger Reihenfolge die Initialisierung als Programmierer vornehmen (welche dann die Initialisierungsreihenfolge definiert), oder
    b) der Compilerbauer dürfte die Initialisierung in beliebiger Reihenfolge vornehmen, abweichend vom Programmcode.

    Im Fall von b) darf man dann in der Tat sich nicht auf die Reihenfolge verlassen, weil man dann als Programmierer keinerlei Kontrolle hätte. Nur was spricht gegen a) ?


Log in to reply