Ist C++ noch zu retten?



  • @Bashar
    Was die können kann ich auch ;).

    Zitat:
    @Enumerator Es muss nicht jeder mit C++ programmieren. Wenn es dir zu komplex ist und du es nicht verstanden hast, dann lass es bleiben. Für dich hat der Herrgott BASIC erfunden.

    @hustbaer
    Ich schätze deine Meinung hier im Forum ja sehr aber mit deinem "Experten"-Kommentar hast du dich wirklich lächerlich gemacht.
    Ich stelle mir gerade vor wie sich Boeing nach den beiden Abstürzen durch das MCAS Debakel hingestellt hätte:

    Die 737 MAX ist halt nur was für Experten zum Fliegen...
    Die Piloten haben den Flieger einfach falsch bedient.
    Man kann sich das Leben so schön einfach machen...

    Solche Statements kommen in der Regel nur von Personen die Pfusch schönreden wollen. Schade dass es in C++ scheinbar keine Diskussion über die vielen Fehlkonstruktionen geben darf. Und auto wird C++ einst den Gnadenstoß versetzen wie einst Dim Visual Basic das Genick gebrochen hat (Ich weiß auto ist "typsicher", von Referenzen mal abgesehen). In C# haben sie die Sprache nun leider auch noch nachträglich um diesen "var" Murks erweitert.



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

    Die Verwendung von auto ist einfach extrem Fehleranfällig weil auto etwas suggeriert was es nicht ist und zu sehr schlecht lesbarem Code führt. Es gibt nunmal sicherheitskritische Bereiche in der Softwareentwicklung wo ein solches Fehlerpotenzial nicht akzeptabel ist.

    OK. Und der Fehler wenn dein Kollege auto verwendet (obwohl er nicht weiss wie es funktioniert) ist dann nicht dass er etwas verwendet wovon er nicht weiss wie es funktioniert sondern dass C++ sowas wie auto überhaupt anbeitet. Komische Einstellung.

    Wie sollte auto denn deiner Meinung nach funktionieren?

    Kleiner Tip: auto var = expression; ergibt den selben Typ für var wie wenn du expression beim Aufruf eines function templates verwenden würdest:

    template <class T>
    void fun(T var);
    
    // ....
        fun(expression);
    

    Das macht mächtig viel Sinn. Alles andere wäre komisch und mMn. viel fehleranfälliger.



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

    Er hätte "auto&" schreiben müssen. Das ist Grund genug für mich auto zu verbieten.

    So ein Quatsch. Das ist ein Anfängerfehler den man ein, zweimal macht und dann nie wieder.



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

    @hustbaer
    Ich schätze deine Meinung hier im Forum ja sehr aber mit deinem "Experten"-Kommentar hast du dich wirklich lächerlich gemacht.

    OK. Lass es mich anders sagen: Wer Sprachkonstrukte verwendet von denen er einfach nicht weiss wie sie funktionieren, darf sich bitte nicht über die Sprache aufregen wenn sie nicht so funktionieren wie es das Stück Code das er damit gebastelt hat gerade brauchen würde.

    Ich stelle mir gerade vor wie sich Boeing nach den beiden Abstürzen durch das MCAS Debakel hingestellt hätte:

    Die 737 MAX ist halt nur was für Experten zum Fliegen...
    Die Piloten haben den Flieger einfach falsch bedient.
    Man kann sich das Leben so schön einfach machen...

    Du vergleichst hier Äpfel mit Birnen.

    Solche Statements kommen in der Regel nur von Personen die Pfusch schönreden wollen. Schade dass es in C++ scheinbar keine Diskussion über die vielen Fehlkonstruktionen geben darf.

    Du kannst mit mir jederzeit eine Diskussion über Fehlkonstruktionen im C++ Standard führen. Da gibt's mMn. einige. auto gehört bloss nicht dazu. Und eine Geschichte von jmd. der es falsch verwendet hat, weil er nichtmal ansatzweise Ahnung davon hatte wie es funktioniert, wird mich nicht vom Gegenteil überzeugen.

    Solche Leute sind ein grosses Problem in der Softwareentwicklung. Was meinst du was los ist wenn du so jemandem etwas wie Threads in die Hand gibtst? Der schreibt dann jahrelang kaputten Code weil's bisher eh immer funktioniert hat. Und irgendwann kommst du drauf dass das Programm manchmal falsch rechnet oder abkackt. Bloss ist dann alles schon so kaputt dass man es nicht mehr in vernünftiger Zeit reparieren kann.

    Und auto wird C++ einst den Gnadenstoß versetzen wie einst Dim Visual Basic das Genick gebrochen hat (Ich weiß auto ist "typsicher", von Referenzen mal abgesehen). In C# haben sie die Sprache nun leider auch noch nachträglich um diesen "var" Murks erweitert.

    Sehe ich anders.
    Und: was soll "von Referenzen mal abgesehen" heissen? Auch da ist es typsicher. Und mMn. auch sicherer gegenüber Falschverwendung als wenn es anders rum wäre.



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

    Zitat:
    @Enumerator Es muss nicht jeder mit C++ programmieren. Wenn es dir zu komplex ist und du es nicht verstanden hast, dann lass es bleiben. Für dich hat der Herrgott BASIC erfunden.

    Der nächste Paragraph geht halt auch mit "Aber jetzt ernsthaft:" los. Kann man beim Zitieren natürlich unterschlagen. Ist dann aber auch irgendwie komisch.

    ps: Ich finde es auch sprechend dass du anscheinend nicht weisst wie man hier im Forum "korrekt" zitiert bzw. es dich nicht schert es korrekt zu machen.



  • Ich glaube wir drehen uns da im Kreis :). Ich wollt doch nur darauf hinweisen, dass auto den Code sehr viel schlechter lesbar macht. Wollt ihr mir erzählen ihr erkennt im folgenden Code dass hier ein & beim auto vergessen wurde:

    Zitat:
    Kleiner Tip: auto var = expression; ergibt den selben Typ für var wie wenn du expression beim Aufruf eines function templates verwenden würdest:

    @hustbaer
    Ja eben genau nicht:

    const vector<int>& GetInts()
    {
        static vector<int> s_ints;
        return s_ints;
    }
    static auto unexpectedCopy = GetInts();
    

    Der Code würde wenn ich nicht total daneben liege eine Kopie des Vectors anlegen. Das ist ja die Krux.

    Da können dann auch ein dutzend Entwickler drüber schauen und erkennen das fehlende & nicht. Dann soll man solche Krücken gefälligst weg lassen. Aber jeder wie er will ich werde auto jedenfalls nicht verwenden :).

    Zum "aber jetzt ernsthaft". Ich schlage auch immer den Leuten erst ins Gesicht und entschuldige mich danach [Ironie off].

    Ja ich gebe zu ich finde die Zitieren Funktion extrem umständlich weil man ja meistens nur eine kleine Passage zitieren möchte und nicht den ganzen Post. Insofern gebe ich dir recht. Ich bin ein Zitier-Legasteniker ;). Mal davon abgesehen, dass das Forum ohne Referrer und Skripte komplett unbenutzbar ist.



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

    Ich glaube wir drehen uns da im Kreis :). Ich wollt doch nur darauf hinweisen, dass auto den Code sehr viel schlechter lesbar macht. Wollt ihr mir erzählen ihr erkennt im folgenden Code dass hier ein & beim auto vergessen wurde:

    Zitat:
    Kleiner Tip: auto var = expression; ergibt den selben Typ für var wie wenn du expression beim Aufruf eines function templates verwenden würdest:

    @hustbaer
    Ja eben genau nicht:

    const vector<int>& GetInts()
    {
        static vector<int> s_ints;
        return s_ints;
    }
    static auto unexpectedCopy = GetInts();
    

    Ja eben genau doch:

    vector<int>& GetInts()
    {
        static vector<int> s_ints;
        return s_ints;
    }
    
    template <class T>
    void appendInt(T container) { // <-- Quatsch
        container.push_back(42);
    }
    
    void fun() {
        appendInt(GetInts());
    }
    

    Hier wird bei appendInt genau so (unerwartet?) eine Kopie angelegt wie in deinem Beispiel. Wie gesagt: die selben Regeln, selbes Ergebnis. Sind deswegen Templates eine einzige riesen Fehlkonstruktion?

    Da können dann auch ein dutzend Entwickler drüber schauen und erkennen das fehlende & nicht.

    Ja, kann passieren. Ich sage auch nicht dass man immer und überall auto verwenden soll. Das heisst aber auch nicht dass auto grundsätzlich schlecht und eine Fehlkonstruktion ist.

    Zum "aber jetzt ernsthaft". Ich schlage auch immer den Leuten erst ins Gesicht und entschuldige mich danach [Ironie off].

    Sowas kommt vor (nicht immer, aber manchmal) wenn jemand einen Beitrag schreibt der für mich so haarstreubend lächerlich (sorry) ist wie deiner hier.



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

    Als ich damals noch in der Luftfahrtbranche gearbeitet hatte

    Würdest du mir die betroffenen Flugzeugtypen nennen? Möchte mich nicht unnötig in Gefahr begeben.
    (EDIT: Ich hatte den post nicht seziert, weil hustbaer das für mich gemacht hatte).



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

    @Bashar
    Was die können kann ich auch ;).

    Aber kannst du sonst noch was? Bisher bist du mir eigentlich nur negativ aufgefallen. Wenn du positiv auffallen möchtest, solltest du dich nicht an denen orientieren, die du kritisierst.



  • @hustbaer
    Achso, jetzt verstehe ich worauf du hinaus wolltest. Aber nochmal. Bei auto erwarte "ich" dass es sich genauso verhalten würde wie ein typedef. Dass das auto den "Typ" bei Referenzen ändert ist für mich einfach ein Unding und unerwartet. Das wird wohl auch niemand ernsthaft in Abrede stellen können. Genauso wie dass es den Code schlechter lesbar macht. Was gewinnt man also durch Verwendung von auto (Ja, ich weis es gibt ein paar wenige Codekonstrukte die ohne auto nicht möglich wären)?

    Grundsätzlich ist das Problem aber auch bei Templates existent. Im Beispiel im Code unten wird man sich wundern warum die spezialisierte Funktion zwar mit Pointern funktioniert, nicht aber mit Referenzen, weil der Compiler die "T" Variante ohne "&" erwarten würde, obwohl eine Referenz an die Print-Funktion übergeben wurde. Findet ihr das wirklich zugänglich? Vor allem wenn sich auto dann womöglich noch anders verhält wie man es aus anderen Sprachen gewohnt ist.

    class A
    {
    template <class T> void Print(T arg);
    };
    
    template <>
    void A::Print(MyObject* arg)
    {
    ...
    }
    
    template <>
    void A::Print(MyObject& arg)
    {
    ...
    }
    

    @Bashar
    @5script
    Sorry, aber darauf gehe ich gar nicht weiter ein.



  • Und was sagt ihr zu den von mir genannten Smart-Pointer Fehlkonstruktionen? Mir ging es eignetlich hauptsächlich darum. Darüber verliert ihr komischwerweise kein einziges Wort. Eisiges schweigen im Walde. Das mit dem auto war nur als kleine Anekdote gedacht. Furchtbar wie ihr euch daran aufhängt weil ihr selber wisst, dass C++ einfach viele Fehlkonstruktionen hat die man auch nicht leugnen kann. Und bitte nehmt es doch nicht persönlich. Man sollte eine Diskussion niemals auf sich selber projezieren. Ich greife hier doch niemanden persönlich an deswegen. Natürlich könnt ihr für die Situation auch nichts. Danke. Ich denke der Thread kann geschlossen werden.



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

    Was ich z.B. total ätzend finde ist, dass man einen Smart-Pointer im Konstruktor nicht mit this initialisieren kann (wenn von enable_weak_from_this abgeleitet)

    Warum würdest du das wollen? Zur Selbsthaltung?

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

    Oder auch siehe zirkuklare Abhängigkeiten und memory leaks.

    Klingt verdächtig nach dem angedeuteten shared_ptr abuse.

    Alles was ich in dem Post lese sind:

    • Mangelhafte Software Architektur.
    • Anfänger C++ beizubringen ist hard und sie machen viele Fehler.

    Für letzteres kann ich auch argumentieren, also will ich das gar nicht kritisieren.



  • Zyklische Abhängigkeiten bei referenzgezählten Zeigern sind ein generelles Problem, das weiß man schon sehr lange und das hat mit der speziellen Konstruktion von shared_ptr nichts zu tun.



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

    Furchtbar wie ihr euch daran aufhängt weil ihr selber wisst,

    Furchtbar, dass du nicht einfach sagen kannst "ja, mit dem auto war quatsch von mir, reden wir doch bitte über smart-pointer".
    Dein smart-pointer-Problem habe ich leider nicht verstanden, sonst hätte ich da was zu gesagt. Wobei wahrscheinlich eher nicht, da ich nur pointer und unique_ptr nutze und mit smart/weak kaum Erfahrung habe.



  • Huch



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

    @hustbaer
    Achso, jetzt verstehe ich worauf du hinaus wolltest. Aber nochmal. Bei auto erwarte "ich" dass es sich genauso verhalten würde wie ein typedef.

    Das ist jetzt ein schlechter Vergleich, da du nicht typedef myFunctionThatReturnsInt() MyNewNameForInt schreiben kannst. Dazu brauchst du declspec. Und bei declspec macht es im Gegensatz zu auto schon Sinn dass Referenzen nicht einfach so verschwinden. Obwohl es auch dort viele Fälle gibt wo man cv-ref weg haben möchte.

    Dass das auto den "Typ" bei Referenzen ändert ist für mich einfach ein Unding und unerwartet. Das wird wohl auch niemand ernsthaft in Abrede stellen können.

    Ich kann nicht in Abrede stellen dass es für dich ein Unding ist. Aber ich bin gänzlich anderer Meinung. Es ist gut dass auto cv-ref wegmacht.

    Genauso wie dass es den Code schlechter lesbar macht. Was gewinnt man also durch Verwendung von auto (Ja, ich weis es gibt ein paar wenige Codekonstrukte die ohne auto nicht möglich wären)?

    auto const x = a + b; // interessiert mich doch nicht die Bohne welchen Type a und b haben
                          // (mal abgesehen davon dass der Typ von `a + b` nicht identisch zum Typ von `a` oder `b` sein muss),
                          // ich will bloss das Ergebnis mit dem passenden Typ einfangen
    auto const it = cont.find(...); // IMO viel lesbarer als ohne auto
    if (it != cont.end())
        ...
    

    Davon abgesehen...

    template <class T>
    T popAndReturnBack(T& cont) {
        auto val = cont.back();
        cont.pop_back();
        return val; // Kaboom nach deinen Regeln, kein Problem mit den echten Regeln
    }
    

    Grundsätzlich ist das Problem aber auch bei Templates existent. Im Beispiel im Code unten wird man sich wundern warum die spezialisierte Funktion zwar mit Pointern funktioniert, nicht aber mit Referenzen, weil der Compiler die "T" Variante ohne "&" erwarten würde, obwohl eine Referenz an die Print-Funktion übergeben wurde. Findet ihr das wirklich zugänglich?

    Nein. Ist aber wieder so ein Fall von Dinge verwenden über die man sich nicht ausreichend informiert hat. Gerade wenn man Code schreibt wo es extrem wichtig ist dass er korrekt funktioniert, darf man das einfach nicht machen. Einfach was hinschreiben von dem man sich denkt es könnte vielleicht die Syntax sein für das was man erreichen möchte, und es ausliefern sobald es compiliert... ohne es getestet zu haben... so kann man einfach nicht vernünftig Software entwickeln. Und wenn man es testet, dann merkt man meistens dass es nicht funktioniert.

    Vor allem wenn sich auto dann womöglich noch anders verhält wie man es aus anderen Sprachen gewohnt ist.

    z.B.?



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

    Eine Klasse wie die shared_ptr Klasse die es zulässt dass man sich selber in das Knie schießt ist broken by design. Da sind wir dann einmal gemeinsam einer Meinung ;). Und Fehler passieren nur Anfängern. Ganz ehrlich diese Arroganz wiedert mich an. Ich hoffe du kommst nie in eine Position mit Verantwortung.

    Ich habe nicht gesagt dass Fehlern nur Anfänger passieren.
    Du hast auch meine Frage nicht beantwortet.
    Ich kann mir auch mit nem Hammer auf die Finger haun, das macht den Hammer nicht broken by Design.

    Ich habe schon eine Zyklische Referenzen mit shared_ptr hinbekommen über lambda capture, wo das lambda in einem std::function war und das wieder als Member des Objekts im shared_ptr und dadurch eine Selbsthaltung ungewollt gebaut.
    So eine Fehler würde ich ja noch akzeptieren. Aber manche billig sachen sind mit Erfahrung einfach mega schnell gefunden.

    shared_ptr hat nunmal ein caveat den man kapiert haben muss.
    Sowieso hoffe ich dass aus guten Gründen zu shared_ptr gegriffen wurde, statt unique_ptr.

    Darüber hinaus möchte ich noch sagen, dass JockelX und hustbaer angesehene Foristen hier sind und das berechtigt hier über Zeit aufgebaut haben. Eine Meinungsverschiedenheit mit denen rechtfertigt eine Selbstreflektion der eigenen Ansicht. Was mich selbst angeht muss ich mich nicht für meinen Source schämen.
    Mein code wird bei Siemens, Bio Unternehmen (Menschen Gesundheit) und Straßenbau verwendet (Messtechnik zur Qualitätssicherung bezüglich grip und audiocharacteristik der Oberfläche).



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

    @Bashar Achso, nichts hat mit nichts zu tun. Und weil es schon immer so war ist es ok.

    Das hab ich nicht gesagt.



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

    Und was sagt ihr zu den von mir genannten Smart-Pointer Fehlkonstruktionen?

    Ich sehe auch diese nicht als Fehlkonstruktionen. Alles was du genannt hast ist doch bloss ein Problem weil jemand glaubt er hätte hier eine Silver-Bullet bekommen, und diese vermeintliche Silver-Bullet dann verwendet ohne sich ausreichend darüber informiert zu haben.

    Ich arbeite seit bald 20 Jahren mit shared_ptr (erst Boost und jetzt eben std), und ich hatte bisher genau einen einzigen Fall an den ich mich erinnern kann wo zykische Referenzen ein Problem waren weil ich nicht daran gedacht hatte. Und nicht weil ich bloss 1x zykische Referenzen gehabt hätte, sondern weil ich mir das Ding damals als ich anfing es zu verwenden angesehen habe, und über das potentielle Problem bescheid weiss. Und weil man das jetzt auch falsch verstehen könnte: zyklische Referenzen sind schon eher selten. Nur halt nicht ganz "1x in 20 Jahren" selten.

    Und auch hier wieder: Was wäre dein Gegenvorschlag? Einer der grossen Vorteile von shared_ptr (im Gegensatz zu z.B. Garbage Collection in Java oder C#) ist dass der Zeitpunkt der Zerstörung und der Thread in dem zerstört wird deterministisch sind. Wie willst du das ohne furchtbar schlechtes Laufzeitverhalten lösen ohne vom Benutzer zu verlangen Zyklen manuell aufzubrechen?

    Und was das "Problem" mit den virtuellen Destruktoren angeht/make_shared vergessen...
    Dass du bei shared_ptr keinen virtuellen Destruktor brauchst ist ein recht spezielles Zusatzfeature/Nebeneffekt - "normal" wäre dass man Klassen die mit Basisklassen-Zeigern verwaltet werden einen virtuellen Destruktor verpasst. Wenn man Angst hat das zu vergessen kann man einfach die entsprechende Compiler-Warnung aktivieren. Und wenn man das nicht will, z.B. weil man da ein bisschen mikrooptimieren will, dann muss man halt aufpassen. Also auch hier wieder eindeutig Falschverwendung weil nicht verstanden.

    Mir ging es eignetlich hauptsächlich darum. Darüber verliert ihr komischwerweise kein einziges Wort. Eisiges schweigen im Walde.

    Dazu habe ich bisher nichts gesagt, weil es übersichtlicher ist sich auf ein Thema zu konzentrieren. Und weil ich die Erfahrung gemacht habe dass es sowieso nicht funktioniert (allgemein, nicht speziell mit dir); wenn ich auf N Dinge in einem Posting N Antworten schreibe, werden davon meist N - 1 ignoriert. Aber du musst natürlich auch hier unterstellen dass wir nur nichts sagen weil wir nichts zu sagen hätten.



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

    Oder von Anfängern häufig gemachter Fehler ein Objekt per new zu erzeugen und dem Basisklassen-Pointer zuzuweisen anstatt die make_XXXX Varianten zu verwenden.

    Das funktioniert:

    shared_ptr<BaseWithNonVirtualDtor> p(new Derived());
    // verwendet
    //     template< class Y >
    //     explicit shared_ptr( Y* ptr );
    // mit Y=Derived -- es wird also passend ein Deleter erzeugt der das Derived korrekt zerstört
    

    Bloss das funktioniert nicht:

    BaseWithNonVirtualDtor* rawP = new Derived();
    shared_ptr<BaseWithNonVirtualDtor> p(rawP);
    

    Nur jetzt erklär mir bitte wie das ein Fehler ist den man leicht machen kann, wenn man ansonsten korrekt mit Polymorphie umgehen kann? Ich meine das kann nicht funktionieren (unabhängig davon wie shared_ptr implementiert ist), das muss man doch sehen. Aber du erwartest dass es trotzdem funktioniert? WTF?


Anmelden zum Antworten