Ist C++ noch zu retten?



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



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

    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.

    Wie soll man es bitte nicht persönlich nehmen wenn du uns unterstellst uns gegen besseres Wissen etwas einzureden? Geht's noch? Das muss dir doch klar sein dass das untergriffig und auch reichlich arrogant ist.

    Davon abgesehen: Ja, C++ hat einige Fehlkonstruktionen. Bloss nicht die von dir genannten.



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


Log in to reply