Ist C++ noch zu retten?



  • @Enumerator

    Aber wenn z. B. in der Luftfahrt ein Fluggerät regelmäßig zu Abstürzen führt weil es für den Piloten schwer einhaltbare Limits hat kann man auch darüber streiten, ob die Piloten alle zu blöd sind und die verlorenen Menschenleben hinnehmen

    Dein Gedankengang bezüglich sicherer Software finde ich wirr. Die Entwicklung einer sicheren Software ist mehr eine Sache des Projektmanagements und weniger eine Sache der Programmiersprache bzw. Coding Styles.

    Es ist beispielsweise überhaupt keine gute Sache, wenn der Produzent einer Sache auch deren Qualitätsprüfer ist, denn dieser neigt zu Fehlerblindheit. Schreibt man beispielsweise eine Ausarbeitung, Paper, oder sonst was und korrigiert diese nur von Hand, so sieht man nach einer gewissen Zeit viele Fehler nicht mehr. Erst wenn man die Ausarbeitung einem Kollegen in die Hand drückt, werden viele Fehler aufgedeckt. Das ist vermutlich die Idee hinter Pair Programming.

    Des weiteren müssen Produkte ausgiebig getestet werden. Das beginnt bei der strikten Sicherstellung gewisser Stufen (Assertions), den konsequenten Aufbau von Testreihen, Black Box Tests, Aufbau und Test von Use-Cases bzw. Anwendungsfällen,... Ein Bug-Bounty-Programm kann da sinnvoll sein.

    Auch eine Analyse der Zuverlässigkeit ala FMEA finde ich im Bereich von sicherer Software für unabdingbar. Welche Elemente können einen GAU auslösen? Wie lassen sich Risiken minimieren? Was passiert wenn XYZ ausfällt? Was passiert wenn Sensor XYZ (z.B. GPS) Bockmist baut? Was passiert beispielsweise wenn der Pilot einen schlechten Tag hat und im Stand das Fahrwerk einziehen möchte? Was passiert wenn der Compiler einen Bug hat und aus (double)65537 -1.0 macht? Ein Coding-Style verhindert solche Fälle nicht.

    Ich finde es auch interresant wann ein Fehler auftaucht. Nicht das schon 100.000 Produkte im Umlauf sind und dann auf einmal ein kritischer Fehler in beispielsweise der Freischaltung gefunden wird. Fehler müssen also frühzeitig erkannt werden, denn sonst wird es schnell teuer.

    All das vermisse ich bei deiner DIskussion



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

    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

    Wenn auto cv-ref beibehalten würde, wie würdest du eine Kopie erstellen, wenn du eine haben wolltest?
    Und schlechter lesbar ist das nicht. Zum einen:

    std::vector<std::map<std::string, std::map<int, double>>>::iterator x = GetStoredIterator();

    Oh, ich wollte eigentlich eine Referenz, springt sofort ins Auge.

    Zum anderen, WILL man das meist nicht lesen. Zu mindestens 99% will man Code grundsätzlich verstehen und nicht ganz im Detail. Und es gibt viele Fälle, wie Lambdas, Boost usw., wo man die Details normalerweise auf keinen Fall sehen will. Es gibt viele boost Konstrukte, die extrem komplizierte, verschachtelte Templates erzeugen (z.B. boost::phoenix). Und die interessieren auch nicht. Wenn ich boost::phoenix verwende, will ich z.B. etwas syntactic sugar haben, und ich würd nie auf die Idee kommen, das als 300 Zeilen "Typ" auszuschreiben.

    Auch wegen den smart pointern sind die Argumente etwas komisch. Es geht effektiv nicht anders. Du wirst vermutlich keine bessere Lösung finden. Das ist ein Werkzeug, das musst du verstehen, und es gibt sehr viele Möglichkeiten, das sinnvoll einzusetzen. Aber das kann man nicht überall einsetzen, ohne drüber nachzudenken.

    Das Argument mit der Luftfahrt sehe ich aber schon. Wie andere auch schon geschrieben haben, muss nicht jeder und überall C++ einsetzen. Ich kenne paar Leute, die in der Luftfahr ADA programmieren. Ob das jetzt unbedingt sein muss, weiss ich auch nicht, aber die Überlegungen sind aus meiner Sicht berechtigt (und natürlich historisch bedingt).
    Die Programmiersprache hat schon einen gewissen Einfluß. Zum einen kann man andere Sprachen mit weniger Erfahrung ähnlich erfolgreich einsetzen, zum anderen verleitet C++ teilweise schon zu Spielereien, die man dann nicht 100% im Griff hat (evtl. weil sich auch erfahrene Entwickler überschätzen).



  • Wie gesagt wir drehen uns im Kreis. Man spricht per Chat auch mal aneinander vorbei. Sorry, wenn ich die ein oder andere Aussage missverstanden/-interpretiert habe.

    @Quiche Lorraine
    Naja, wenn wir uns jetzt auch noch darüber unterhalten was ich alles NICHT gesagt habe wird das wohl der längste Thread ever :D. Bis auf deinen ersten Satz würde ich dir aber zustimmen. Aber Sicherheit fängt natürlich auch schon bei der Sprache selber an.

    @hustbaer
    Natürlich kann man jetzt beliebige Beispiele konstruieren für Pro und Contra :). Was wenn ich hier das const weglasse. Das hast du ja mit gutem Grund hingeschrieben ;). Ist das Ganze dann immer noch lesbar wenn ich bei z. B. späteren Typkonvertierungen erstmal überlegen muss welchen Typ eine Variable überhaupt hat? Ich würde meinen Kollegen niemals ein solches Ratespiel zumuten. Und genau sowas führt (so meine Erfahrung) halt auch schnell mal zu unnötigen Fehlern.

    auto const x = a + b;
    

    Ich sehe jedenfalls keinen Gewinn durch weglassen von Informationen :(. Ob das lesbarer ist ist aber sicherlich auch irgendwo eine Glaubensfrage klar.

    Die letzten Jahre habe ich zugegeben mit einigen Studienabsolventen zu tun gehabt und einfach gesehen, dass trotz dieser "Smarten" Klassen mehr Fehler gemacht wurden als von älteren Kollegen die sich noch die rohen Zeiger um die Ohren geschmissen hatten, um es etwas überspitzt zu formulieren. Zuweilen gingen die Fehler dann aber eben auf wenn man es streng sieht Unzulänglichkeiten der Sprache zurück. U.a. nämlich auf die von mir genannten Probleme. Und ich würde einem C++ Anfänger daraus auch keinen Vorwurf machen. Den Vorwurf mache ich in diesen Fällen einfach C++.

    Und andere Sprachen zeigen doch, dass es prinzipiell auch anders geht. Warum verteidigt ihr das dann noch? Ich würde mir wünschen dass C++ an der ein oder anderen Stelle solider und vor allem einheitlicher/konsequenter wäre und auch einige Features z. B. aus C++20 kommen einfach viel zu spät. Die Smart-Pointer - die shared_ptr Klasse insbesondere - fühlen sich einfach wie ein nachträglich hinzugefügtes Flickwerk an, weil man nie den Mut hatte die Sprachsyntax von C++ selber konsequent anzupassen. Das man das nicht getan hat kann ich auch nachvollziehen. Dafür gab es ja Grüde wie Abwärtskompatibilität, "You Pay Only For What You Use". Das Ergebnis ist halt nicht optimal. Ich glaube auch ein harter Cut wäre langfristig die bessere Lösung gewesen. Nichts desto trotz ist es nach wie vor meine Lieblingssprache. Aber wie gesagt. Ich wünschte mir ein Sprache wie C# so hardwarenah wie C++. Ich programmiere nebenher ein Framework mit mittlerweile über 800 Klassen. Seit Jahren kämpfe ich praktisch nur noch mit sprachsyntaktischen Problemen die in anderen Sprachen einfach eleganter und solider gelöst sind bzw. werden können. Ständig muss man irgendwelche Hacks machen was einfach von der Hand gehen könnte.

    Warum hat Qt wohl einen eigenen Präprozessor entwickelt? Doch nicht weil sie Lust dazu hatten, sondern weil die Möglichkeiten in C++ unzureichend waren. Mit den Problemen bin ich ja nicht alleine auf der Welt. C++ ist was moderne Entwicklung anbelangt einfach ein Stück weit abgehängt.

    @Mechanics

    Wenn auto cv-ref beibehalten würde, wie würdest du eine Kopie erstellen, wenn du eine haben wolltest?

    Welches auto? Problem gelöst ;).

    std::vector<std::map<std::string, std::map<int, double>>>::iterator x = GetStoredIterator();

    Ich will das tatsächlich sehen :). Die std und boost sind aber auch teilweise von "Template Fetischisten" geschrieben. So krass habe ich das noch nie bei anderen Sprachen erlebt (Templategeschwurbel über 10 Zeilen usw.). Davon abgesehen könnte man die Map im Vector in eine separate Klasse packen. Das Beispiel ist also insofern ein wunderbares Beispiel wie es nicht sein sollte :).

    Aber alles klagen nützt ja nichts. Es ist wie es ist.



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

    Wie sollte auto denn deiner Meinung nach funktionieren?

    Gar nicht! Es sollte überflüssig sein, wenn ich den Typ nicht kenne, oder der Typ zu kompliziert ist, habe ich ein Problem im Design der Programmiersprache. Dazu macht auto Probleme bei simplen Definitionen mit Zuweisung

    auto i = 10;
    

    Ok, wir wissen alle dass Zahlenliterale als Standardtyp int haben, aber anstatt so einen Unsinn zu verbieten, und die Altlasten aus C endlich zu entsorgen, wird nun das zweite Typsystem nun ausgebaut. Was soll der Schwachsinn? Bei solchen Zuweisungen gibt grundsätzlich zwei Möglichkeiten, der Compiler bekommt die Freiheit den kleinstmöglichen Datentyp zu nutzen, in dem das Literal ohne Verluste umgewandelt werden kann, oder der Entwickler schreibt explizit den Typ hin. Wir haben bereits ein Typsystem short, int, … da brauchen wir kein zweites als Anhängsel der Literale. Das ist überflüssig und fehleranfällig. Wenn das Literal nicht in den angegeben Typen ohne Verluste umgewandelt werden kann, soll der Compiler einen Fehler werfen. Es geht in so vielen anderen Programmiersprachen doch auch.

    Wenn nun der Einwurf Lambdas kommt, deren Datentypen ist ein Alptraum, es wäre vielleicht sinnvoller gewesen auf Lambdas zu verzichten und das ganze sauber anders zu lösen.



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

    Es sollte überflüssig sein, wenn ich den Typ nicht kenne

    und wie deklarierst du dann die variable?

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

    Wenn der Typ zu kompliziert ist, habe ich ein Problem im Design der Programmiersprache

    Jede streng typisierte Sprache mit generics ist so.

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

    Bei solchen Zuweisungen gibt grundsätzlich zwei Möglichkeiten, der Compiler bekommt die Freiheit den kleinstmöglichen Datentyp zu nutzen

    Warum?

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

    oder der Entwickler schreibt explizit den Typ hin

    auto a = 0ull;

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

    Wenn das Literal nicht in den angegeben Typen ohne Verluste umgewandelt werden kann, soll der Compiler einen Fehler werfen

    [[maybe_unused]] short a = 1'000'000ull;

    warning: overflow in conversion from 'long long unsigned int' to 'short int' changes value from '1000000' to '16960' [-Woverflow]|

    Ich verstehe nicht was du damit sagen willst.



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

    Die std und boost sind aber auch teilweise von "Template Fetischisten" geschrieben. So krass habe ich das noch nie bei anderen Sprachen erlebt (Templategeschwurbel über 10 Zeilen usw.).

    Weil das in anderen Sprachen meist nicht so relevant ist. C++ ist so ausgelegt, dass man möglichst viel im Griff hat und im Griff haben will. In den meisten anderen Sprachen macht man sich viel seltener Gedanken über Details, und dementsprechend seltener gibt es irgendwelche "generischen" Bibliotheken.
    In C# wird selten jemand nach Containern außer List und Dictionary suchen. In Java erzwingt man z.B., dass man irgendwelche Schnittstellen implementieren muss, z.B. Comparable. Und wenn man keine virtuellen Funktionen will, oder nicht will, dass alles von Object ableitet, oder mal unterschiedliche Vergleichskriterien haben will... Das sind alles Einschränkungen, die meist egal sind, wenn man sich auf eine Sprache spezialisiert hat, aber die man in C++ zum Glück nicht haben will.
    Und dann kommen eben Klassen mit paar Template Parametern zusammen. Und die kann man vielleicht eben zusammenstecken, zu sowas wie z.B. boost::multi_container.
    Wie schon öfter gesagt, das ist nicht für jeden etwas. Ich habe auch eine Weile gebraucht, um mich an C++ zu gewöhnen. Aber ich sehe das alles als große Vorteile und die Flexibilität finde ich super. Und wenn man das nicht will, dann muss man das auch in C++ nicht benutzen.



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

    und wie deklarierst du dann die variable?

    Denn solltest Du aber kennen, weil es sonst einen Rattenschwanz an Problemen geben kann.

    Jede streng typisierte Sprache mit generics ist so.

    Erzähl das mal Ada, und C++ 1998 kam auch ohne aus. In Templates ist es auch überflüssig, weil man genau genommen, wenn man es braucht einen weiteren nicht deklarierten Template Parameter hat. Führt man den explizit ein, hast Du das Problem gelöst.

    auto a = 0ull;

    Nein, genau das nicht, weil man ein zweites Typsystem kennen muss. So sollte es aussehen

    unsigned long long a = 0;
    

    [[maybe_unused]] short a = 1'000'000ull;

    warning: overflow in conversion from 'long long unsigned int' to 'short int' changes value from '1000000' to '16960' [-Woverflow]|

    Ich verstehe nicht was du damit sagen willst.

    Da sollte einfach

    short a = 1'000'000;
    

    stehen, und dann ohne weiteres Compilerflag einen Fehler melden.



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

    Da sollte einfach
    short a = 1'000'000;
    stehen, und dann ohne weiteres Compilerflag einen Fehler melden.

    Wer ohne -Wall kompiliert hat kontrolle über sein Leben verloren.
    @john-0 sagte in Ist C++ noch zu retten?:

    weil man ein zweites Typsystem kennen muss

    Was für ein zweites Typsystem?

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

    C++ 1998 kam auch ohne aus.

    Hast du C++03 und früher schon mal geschrieben? Ich schon.
    Du scheinbar nicht.

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

    Denn solltest Du aber kennen, weil es sonst einen Rattenschwanz an Problemen geben kann.

    ??



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

    Wer ohne -Wall kompiliert hat kontrolle über sein Leben verloren.

    Es geht nicht darum, was ich so mache oder nicht sondern darum, dass bestimmte Fehler erkannt werden müssen, und nicht durch den Compiler rutschen dürfen, weil man ein paar Flags nicht gesetzt hat. Persönlich nutze ich minimal -std=c++17 -pedantic -Wall' (bzw. die gesetzte C++ Version) und oftmals -Wextra‌.

    Was für ein zweites Typsystem?

    Es fällt Dir gar nicht auf? Die Literalzusätze wie das ull sind ein Typsystem, in den Formatstrings hast Du dann ein weiteres.

    Hast du C++03 und früher schon mal geschrieben? Ich schon.
    Du scheinbar nicht.

    Genau diese Grosskotzigkeit, macht Diskussionen im Forum zu einem Problem. Ich kenne C++ von vor der ISO Normierung konkret war es die 2. deutsche Auflage von Stroustrups Buch.



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

    Es fällt Dir gar nicht auf? Die Literalzusätze wie das ull sind ein Typsystem, in den Formatstrings hast Du dann ein weiteres.

    Merkwürdige Definition von "Typsystem".



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

    Genau diese Grosskotzigkeit, macht Diskussionen im Forum zu einem Problem. Ich kenne C++ von vor der ISO Normierung konkret war es die 2. deutsche Auflage von Stroustrups Buch.

    Weil es mich nervt, dass unsinn geblubbert wird und dann so getan wird als sei es das Maß aller Dinge.

    Und was du kennst ist mir egal, mir gehts um die Praxis.
    Und wenn du C++ entwickelt hast vor c++11, dann wär dir aufgefallen was auto und co für unglaublich geile verbesserungen für die Sprache waren.
    Ich kann mich noch gut dran erinnern. Mittlerweile kann ich nicht mehr ansatzweise zurück.
    Ich würde mich quälen.

    "ein zweites Typsystem" - was für ein purerer bullshit.
    "den kleinsten möglichen typ" was für ein bullshit. Warum?

    auto bla = 0;
    bla += 2000;
    

    Javascripts == ist das produkt dieser "die Sprache muss ez fehlerfrei zu benutzen sein" denke.
    Der größte Dreck, weil es automatisch alles praktisch hin und her konvertiert mit obstrusen regeln.

    Und dann guck dir Java an. Der Versuch alles zu machen, dass es schwer ist falsch zu programmieren.
    Java unterscheidet sich in vielem nicht mehr von C++ mit mehr nervigen Limitierungen.

    Die (Bugs / Code) Zahl ist für jede Programmiersprache gleich btw. (EDIT: pi*daumen, es gibt unterschiedliche Ansätze, wie nebeneffekt freie funktionale programmierung, strenge typisierung, ...)



  • Wenn du Fehlerfrei programmieren willst, programmier Haskell.
    Viel Spaß.
    Willst du ein "besseres C++"?
    Programmier D.

    https://imgs.xkcd.com/comics/standards.png
    Ist das gleiche mit Programmiersprachen



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

    Weil es mich nervt, dass unsinn geblubbert wird und dann so getan wird als sei es das Maß aller Dinge.

    Du schließt von Dir auf andere, Du wertest hier andere Meinungen ab, und regst Dich auf, wenn man Deine Meinung nicht teilt. "Unsinn, Geblubber, Bullshit, …" sind nicht die Worte, die man wählt, wenn man eine Diskussion führen will, und zeigen sehr deutlich, dass Du es bist, der seine Meinung zum absoluten Maßstab überhöht.

    Und wenn du C++ entwickelt hast vor c++11, dann wär dir aufgefallen was auto und co für unglaublich geile verbesserungen für die Sprache waren.

    Ich sehe das halt nicht so. Für mich ist auto ein klarer Designfehler motiviert durch Faulheit, und Faulheit war noch nie ein guter Ratgeber für Designentscheidungen.

    "ein zweites Typsystem" - was für ein purerer bullshit.

    Literale existieren nur zum Übersetzungszeitpunkt und haben ihre eigenen Typen, die dann in die eigentliche C++ Typen konvertiert werden. In Deinem Beispiel entspricht das ull dem unsigned long long. Es ist aber kein Typealias oder Typedef für die POD-Typen, sondern ein eigener nur fürs Literal. Wozu werden parallel in einer Sprache drei komplette Sätze an Typen für PODs gepflegt: einer nur für Literale, einer für Formatstrings und dann einer für die eigentlichen Datentypen?

    "den kleinsten möglichen typ" was für ein bullshit. Warum?

    Weil man Datentypen mit kleineren Wertebereich verlustfrei in größere Typen konvertieren kann, und umgekehrt das nicht gültig ist. Wenn der Compiler also automatisch einen Typ wählte, wäre das sinnvoller als irgend einen anderen Typ zu nehmen, weil man dann im Programm ohne weitere Laufzeitprüfung diesen Typ konvertieren könnte. Die beste Lösung ist es explizit den Typ zu wählen, und zwar nicht verpackt im Literal.

    Also in Pseudocode, weil es C++ ja eben nicht so macht

    auto i = 100; // wäre hier dann short (char lassen wir mal absichtlich außen vor, noch so eine C Altlast, es gibt kein Byte)
    int j = j + i;
    
    // würde der Compiler stattdessen automatisch long long wählen
    auto i = 100; // Typ long long
    int j = i; // und schon haben wird ein potentielles Problem
    

    Wenn ich nun den Typen explizit hinschreibe, ist es klar welcher Type es sein soll.

    auto i = 100ull;
    //
    unsigned long long i = 100;
    

    Was gewinne ich mit der auto-Variante? Ich spare ein paar Zeichen ein, und muss das zweite Typsystem für die Bezeichnung der Literale kennen, und es muss natürlich in der Sprache gepflegt werden. Was ist also die Motivation hier bei Variante mit auto – Faulheit! Man verliert dadurch aber Klarheit bei der Formulierung, und das erschwert das Lesen des Codes.



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

    Was gewinne ich mit der auto-Variante?

    Ja dann schreib halt nicht auto i = 0; Hab ich auch noch nie gemacht. Find ich völlig uninteressant. Aber allein schon, wenn man nicht jedesmal std::map<int, int>::const_iterator ausschreiben muss, ist ein Gewinn. Und bei den noch komplizierteren Templates sowieso.



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

    Weil man Datentypen mit kleineren Wertebereich verlustfrei in größere Typen konvertieren kann

    unnötiger overhead. Außerdem entsteht dann die Notwendigkeit zu wissen mit welchem Wert die Variable initialisiert wurde.
    Was für kern-bescheuerter Vorschlag wenn man argumentiert dass auto code obfuscated.
    EDIT: Du hast mein Beispiel schon wieder ignoriert.

    for (auto i = 0; i != 1000; ++i) // <- auto deduziert als unsigned char?
    {
    }
    

    Argumentier mal warum das gut ist bitte.
    Hier bitte auch:

    auto foo()
    {
        return 2;
    }
    
    int main()
    {
        auto bla = foo(); // fml
    }
    

    Außerdem warum ziehst du dich an auto für Zahlen hoch?
    Auto für integrale datentypen interessiert doch kein mensch. Auto lohnt sich erst für komplexere Typen und rückgabewerte.

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

    Literale existieren nur zum Übersetzungszeitpunkt und haben ihre eigenen Typen, die dann in die eigentliche C++ Typen konvertiert werden. In Deinem Beispiel entspricht das ull dem unsigned long long. Es ist aber kein Typealias oder Typedef für die POD-Typen, sondern ein eigener nur fürs Literal. Wozu werden parallel in einer Sprache drei komplette Sätze an Typen für PODs gepflegt: einer nur für Literale, einer für Formatstrings und dann einer für die eigentlichen Datentypen?

    Und jetzt erklär mir nochmal warum C++ mehr als ein Typsystem beinhaltet.

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

    Ich sehe das halt nicht so. Für mich ist auto ein klarer Designfehler motiviert durch Faulheit, und Faulheit war noch nie ein guter Ratgeber für Designentscheidungen.

    Diese Sätze sind inhaltlich wertlos.

    EDIT: Ich hab nicht mehr die innerer Ruhe wie früher. Ich glaube ich stell das antworten hier erstmal ein, bevor ich verbal entgleise und ein bann kassier.



  • Ich sehe ebenfalls in auto einen großen Gewinn. Irgendwelche verschachtelten Typen, von denen man die Namen nicht mehr kennen muss, Benutzbarkeit von Iteratoren, Lambda-Funktionen (da ist der Typ nicht bekannt und auto ist erzwungen) etc.

    Wo ich auto nicht benutze:
    auto i {0};
    stattdessen finde ich dort
    int i = 0;
    einfach besser lesbar.

    Es kommt also - wie eigentlich immer - stark darauf an, worauf du in einem Codeteil gerade den Fokus legen willst. Wenn du rechnest und numerisch simulierst, finde ich konkrete Typen sehr hilfreich. Wenn es irgendein Proxy-Objekt ist, das irgendwo aus einer Klassenhierachie kommt und von dem du weißt, dass es die Member-Funktion int getMyData() hat, dann auf jeden Fall auto nehmen, denn was interessiert mich das konkrete Implementationsdetail "Typname", der da zwischendurch auftritt. Am Ende finde ich das int als Rückgabetyp, der wirklich von Interesse ist, wieder gut. Ähnlich mit den Iteratoren. Ich muss den Typen von *it kennen, der von it selbst ist mir wumpe. Ohne auto kommt bei Iteration über verschachtelte getemplatete Typen die helle Freude auf!

    Allerdings finde ich die Regeln für auto logisch und den Unterschied zwischen auto und auto & oder bevorzugt const auto& absolut eindeutig. Ich mache auch sehr viel Python, wo es duck typing gibt. Auch oft kein Problem. Man braucht die exakten Typen nicht überall zu kennen.

    Zu den Smartpointern: ich finde die gut, benutze aber zu weit überwiegend unique_ptr und nur selten shared_ptr (und das meist nicht wegen sharing, sondern weil ich einen custom deleter haben will und das durch das Type-Erasure einfach gemacht wird). Kommt sicher darauf an, was du so machst - ich habe das enable_share_from_this bislang nocht nicht gebraucht und kann mich daher hier nicht qualifiziert äußern. Nur: bist du sicher, dass dein Design sinnvoll ist? Gerade zirkuläre Abhängigkeiten und unklare Ownership können auf ein Designproblem hindeuten. (nicht falsch verstehen: können != müssen)



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

    Was wenn ich hier das const weglasse.

    Na dann ist die Variable halt nicht const. Ansonsten ändert sich am Typ nichts.

    Das hast du ja mit gutem Grund hingeschrieben ;).

    Ich schreib da auch const hin wenn es int const ist. Weil es den Code einfacher zu lesen macht, wenn man bei der Definition schon sieht dass der initiale Wert nicht mehr geändert wird.

    Ist das Ganze dann immer noch lesbar wenn ich bei z. B. späteren Typkonvertierungen erstmal überlegen muss welchen Typ eine Variable überhaupt hat? Ich würde meinen Kollegen niemals ein solches Ratespiel zumuten.

    Ja ganz schlimm. [/sarcasm]
    Ich kenne komischerweise einige Leute die bei folgendem Code heulen und jammern was für ein furchtbares Ratespiel es doch ist den Typ zu ermitteln

    void fun(TypeA a, TypeB b) {
        auto const x = a + b;
        auto const y = fun2(x);
        auto const z = bar.foo();
        fun3(z);
    }
    

    aber folgenden Code 100.00% supi A-OK finden:

    void fun(TypeA a, TypeB b) {
        fun3(fun2(a + b).foo());
    }
    

    Und das ist einfach nur bescheuert.

    Die letzten Jahre habe ich zugegeben mit einigen Studienabsolventen zu tun gehabt und einfach gesehen, dass trotz dieser "Smarten" Klassen mehr Fehler gemacht wurden als von älteren Kollegen die sich noch die rohen Zeiger um die Ohren geschmissen hatten, um es etwas überspitzt zu formulieren.

    Leute mit weniger Erfahrung machen mehr Fehler als Leute mit mehr Erfahrung. Das ist Fakt. Und Studienabsolventen haben meist kaum Erfahrung was Programmieren angeht. Ebenso Fakt. Wenn du jetzt statt dessen behauptest dass die höhere Fehlerrate Schuld der Sprache ist, dann weiss ich nicht was ich noch dazu sagen soll.

    Zuweilen gingen die Fehler dann aber eben auf wenn man es streng sieht Unzulänglichkeiten der Sprache zurück.

    Ich hab in dem Absatz den du so schlimm fandest schon darauf hingewiesen dass C++ ein Tool für Profis ist. Das war kein Scherz. Ja, C++ ist komplex. Dafür kann man auch einiges damit machen. Dass jemand mit wenig C++ Erfahrung schlechten C++ Code mit vielen Fehlern schreiben wird, ist klar. Das heisst aber nicht dass C++ grundsätzlich eine Fehlkonstruktion ist -- und auch nicht dass die von dir kritisierten Features eine Fehlkonstruktion sind.

    U.a. nämlich auf die von mir genannten Probleme. Und ich würde einem C++ Anfänger daraus auch keinen Vorwurf machen. Den Vorwurf mache ich in diesen Fällen einfach C++.

    Den Vorwurf mache ich hier Leuten die Noobs einstellen und mit denen ohne die nötigen Prozesse Software für Flugzeugsteuerungen entwickeln wollen. Egal in welcher Sprache.

    Und andere Sprachen zeigen doch, dass es prinzipiell auch anders geht.

    Welche? Beispiel?

    Warum verteidigt ihr das dann noch?

    Ganz einfach: WEIL DU NICHT RECHT HAST. Wie dick kann ein Schädel sein? Ja, es gibt Sprachen die "sicherer" sind als C++. Die meisten davon sind aber auch deutlich weniger mächtig. Und was das wichtigste ist: Selbst mit der sichersten Sprache wirst du einen Affen oder auch durschnittlichen Studienabgänger nicht hinsetzen und Code schreiben lassen können, und dann erwarten dass der einfach so passt. (Also erwarten kannst du es schon, es wird bloss nicht funktionieren.) Jede Sprache die hinreichend mächtig ist, hat auch ordentlich Fehlerpotential. Das ignorierst du aber einfach. Muss Schuld der Sprache sein.

    Die Smart-Pointer - die shared_ptr Klasse insbesondere - fühlen sich einfach wie ein nachträglich hinzugefügtes Flickwerk an, weil man nie den Mut hatte die Sprachsyntax von C++ selber konsequent anzupassen. Das man das nicht getan hat kann ich auch nachvollziehen. Dafür gab es ja Grüde wie Abwärtskompatibilität, "You Pay Only For What You Use". Das Ergebnis ist halt nicht optimal.

    Ich hab dich vorhin schon gebeten mal konkrete Beispiele zu bringen was man genau besser machen könnte, und wie. So lange du das nicht tust, ist das Thema für mich durch.

    Ich programmiere nebenher ein Framework mit mittlerweile über 800 Klassen. Seit Jahren kämpfe ich praktisch nur noch mit sprachsyntaktischen Problemen die in anderen Sprachen einfach eleganter und solider gelöst sind bzw. werden können.

    Dann ist meine starke Vermutung, dass du einfach nicht gut C++ kannst. Wenn es dir schon zu kompliziert war dir zu merken dass man hier im Forum zitieren kann indem man > an den Anfang einer Zeile schreibt

    tadaa

    dann muss ich annehmen dass du von C++ quasi keinen Plan hast und das alles halb im Blindflug machst. Eine Annahme die auch gut zu den Beiträgen passt die du hier schreibst.

    Warum hat Qt wohl einen eigenen Präprozessor entwickelt? Doch nicht weil sie Lust dazu hatten, sondern weil die Möglichkeiten in C++ unzureichend waren.

    Qt ist halt auch sehr alt, da war von C++11 noch keine Rede.

    Mit den Problemen bin ich ja nicht alleine auf der Welt. C++ ist was moderne Entwicklung anbelangt einfach ein Stück weit abgehängt.

    "Moderne Entwicklung" ist aber auch alles andere als sauber oder sicher. Ich weiss also nicht was das genau für ein Massstab sein soll.

    Die std und boost sind aber auch teilweise von "Template Fetischisten" geschrieben. So krass habe ich das noch nie bei anderen Sprachen erlebt (Templategeschwurbel über 10 Zeilen usw.).

    Bitte gib mal zwei Beispiele von Sprachen die ebenso Templates haben und wo das weniger krass ist. Tip: C# zählt nicht denn C# hat keine Templates.



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

    unnötiger overhead. Außerdem entsteht dann die Notwendigkeit zu wissen mit welchem Wert die Variable initialisiert wurde.

    Ah, also das was jetzt schon der Fall ist.

    Was für kern-bescheuerter Vorschlag wenn man argumentiert dass auto code obfuscated.
    EDIT: Du hast mein Beispiel schon wieder ignoriert.

    for (auto i = 0; i != 1000; ++i) // <- auto deduziert als unsigned char?
    

    Wo bitte ist denn der qualitative Unterschied zum status quo?

    for (auto i = 0; i != 10'000'000'000; ++i) {
    

    Das geht aktuell doch auch schon nicht. Der Punkt ist, dass an dieser Stelle auto Unfug ist.
    Schreibt man stattdessen

    for (auto i = 0, e = 10'000'000'000; i != e; ++i) {
    

    motzt der Compiler herum, dass die Deduktion des Typen nicht funktioniert, weil i und e unterschiedlich groß sein sollen. D.h. auch so löst man das Problem nicht. Man muss ohnehin explizit den Typ hinschreiben. Die beste Lösung ist es,

    for (size_t i = 0, e = 10'000'000'000; i != e; ++i) {
    

    zu schreiben bzw. den geeigneten Typ der Wahl. Das löst das Problem.

    Hier bitte auch:

    auto foo()
    {
        return 2;
    }
    
    int main()
    {
        auto bla = foo(); // fml
    }
    

    Warum sollte ich argumentieren, dass daran etwas gut sei? Ich bin derjenige, der sagt, dass auto schlecht ist. Aber wenn man sich damit auseinandersetzt, wo bitte ist denn der qualitative Unterschied zum status quo? Ob der Returntype von foo nun byte wäre oder int ist, macht doch qualitativ keinerlei Unterschied.

    Außerdem warum ziehst du dich an auto für Zahlen hoch?

    Weil das zu Problemen führt, wie Du ja gerade selbst zu erkennen beginnst.

    Auto für integrale datentypen interessiert doch kein mensch. Auto lohnt sich erst für komplexere Typen und rückgabewerte.

    Da spart es Code, aber zu einem Preis, dass verdeckt wird um welchen Typen es sich handelt. Es ist ja nicht so, dass man das Problem vor C++11 nicht gelöst hätte. auto erweitert die Sprache nicht um neue Konzepte, sondern erspart im besten Fall Schreibarbeit. Das Problem dabei ist, dass man i.d.R. Anforderungen an den gelieferten Typen stellt, d.h. man erwartet da als Rückgabewerte nicht irgend einen Typ sondern einen ganz konkreten. Man fängt hier also an mit impliziten Interfaces zu arbeiten und das widerspricht gerade dem Gedanken einer stark typisierten Programmiersprache. Wer SmallTalk will, soll's auch benutzen.

    Und jetzt erklär mir nochmal warum C++ mehr als ein Typsystem beinhaltet.

    Die Typbezeichner für die Literale und die PODs sind disjunkt. Man kann nicht ull a = 1'000'000'000 schreiben, sondern man muss unsigned long long oder auto auf der linken Seite verwenden, und umgekehrt kann man nicht auto a = unsigned long long 1'000'000'000 schreiben. D.h. Literale und PODs verwenden unterschiedlichen Typen, wobei man die Werte von Literale an korrespondierende POD Typen zuweisen kann.



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

    Allerdings finde ich die Regeln für auto logisch und den Unterschied zwischen auto und auto & oder bevorzugt const auto& absolut eindeutig. Ich mache auch sehr viel Python, wo es duck typing gibt. Auch oft kein Problem. Man braucht die exakten Typen nicht überall zu kennen.

    Genau darum geht es. C++ ist eine stark typisierte Sprache und eben keine schwachtypisierte Sprache wie etwa SmallTalk bei der man DuckTyping nutzt. Wenn man Interfaces nutzt, so soll das auch klar und deutlich dokumentiert sein und nicht implizit im Code verstreut sein. Jeder der länger C++ Templates nutzt kennt noch die absolut grausamen Fehlermeldungen, wenn man unpassende Typen an Templates übergab. Daraus erwuchs der Gedanke Konzepte in C++ einzuführen, weil implizite Interfaces zu total kryptisches Fehlermeldungen führte, da der Ort der Falschverwendung und der Ort der Fehlermeldung auseinander lagen bzw. sogar noch liegt.



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

    Genau darum geht es. C++ ist eine stark typisierte Sprache und eben keine schwachtypisierte Sprache

    Mir geht es aber darum, dass ich nicht an allen Stellen meines Codes die starken Typen brauche. Manchmal sind sie sinnvoll, dann nutzt man dort halt kein auto oder nur sporadisch auto. Manchmal aber machen starke Typen einem das Leben schwerer, ohne Mehrwert zu bieten - mehr noch, wenn man später man einen Typen in der Implementierung austauscht, muss man gleich überall Typen anpassen. Und wenn du jetzt argumentierst, dass Details nicht nach draußen leaken sollen, dann hast du generell zwar recht, aber oft lässt sich das nicht vermeiden oder es bietet Optimierungspotential oder die Implementierung wäre ungleich teurer (in Programmiererstunden).

    Für ein vollständiges Programm können in unterschiedlichen Stellen unterschiedliche Paradigmen sinnvoll sein.


Anmelden zum Antworten