C++ - etwas Kontroverses zum Jahresende

[starcow]

*duck - und weg*
Nein, Spass! Ich bin vor einiger Zeit auf dieses Video gestossen und kann es euch nicht vorenthalten.
Meine Kompetenz in C++ reicht für viele seiner Positionen nicht aus, um diese wirklich beurteilen zu können.

1:15:30 ist allerdings klar falsch, da weder in C, noch in C++ eine unvollständige (Teil-) Initialisierung möglich ist (nicht explizit initialisierte Komponenten eines struct oder class werden bei einer Teil-Initialisierung bekanntlich mit dem Wert 0 initialisiert).

Wie beurteilt ihr diese "Abrechnung"? Wo hat er recht - wo nicht?

Euch allen einen schönen Slivester!

[Krishty]

Ich werde das wahrscheinlich nicht ganz schauen, aber betreffend diese eine Folie über Initialisierung dürftest du richtig liegen. Konkret: nicht initialisierte Member werden default-initialisiert; für native Typen entspricht die Default Initialization einer Value Initialization mit 0. Spricht nicht für die Sprache, beruhigt dich aber hoffentlich. Frohes Neues!

[Jonathan]

*duck - und weg*

Ich war als Teenager vermutlich ein unerträglicher Fanboy, aber nur weil ich immer noch (für Spieleentwicklung) bevorzugt C++ verwende, heißt das heutzutage nicht, dass ich nicht viel daran kritisieren könnte. Damals wäre mir so ein Video also vlt. sauer aufgestoßen, heute bin ich da tatsächlich etwas erwachsener, wie ich mir einbilden möchte.

Ich habs jetzt auch noch nicht geguckt, aber was mir auch ohne das klar ist, ist, dass C++ super viele schlimme Altlasten hat, die man auch nicht so einfach los werden kann. Vieles was moderne Sprachen heute besser machen, wird man also einfach nie los werden. Oh well :D

Witzigerweise wollte ich mal zu Rust überwechsel, hab dann aber aufgrund eines ähnlichen Artikels den Schritt nie gemacht:

https://loglog.games/blog/leaving-rust-gamedev/

Vielleicht schau ich mir das andere Video auch irgendwann mal an, aber ehrlich gesagt, erwarte ich nicht viel praxisrelevantes davon. Auch 1-12 neue Kritikpunkte werden mich nicht mein Verhalten ändern lassen, hauptsächlich, weil ich dann ja meine Jahrzehnte alte Codebase aufgeben müsste. Das wird so schnell nicht passieren.

[Jonathan]

Wie beurteilt ihr diese "Abrechnung"? Wo hat er recht - wo nicht?

Hab mal anlässlich eines eigenes Problems kurz reingeschaut. Ein paar Punkte die er anspricht erscheinen mir etwas naiv ("guck mal wie hässlich das ist" - ja, weil man das so halt auch nicht machen soll...), aber andere Dinge stimmen halt auch.

Gestern wollte ich eine Referenz auf ein Element in einen std::vector speichern. Ich wollte die Position wissen, weswegen Zeiger rausfielen, also dachte ich mir, das "schönste" wäre wohl ein Iterator. Aber meine Referenz muss auch auf gar nichts verweisen können, was natürlich mit einem .end() geht - bloß leider werden Iteratoren ungültig, wenn sich der Vektor ändert. Ich müsste also jedes mal wenn ich ein Element hinzufügen will vorher prüfen ob meine Referenz end() war und dann danach aktualisieren. Ja, ne, da nehm ich doch lieber einen int. Den kann ich auf -1 prüfen, das funktioniert immer, und er hat auch nicht wirklich irgendwelche Nachteile gegenüber Iteratoren. Danke für gar nichts...

(Für Container wie std::list sind Iteratoren wohl weniger nutzlos, und vermutlich hat der std::vector sie auch nur bekommen, damit es einheitlich ist, und nicht, weil Iteratoren für vectoren irgendwie nützlich wären - zumindest fällt mir kein echter Nutzen ein...)

[starcow]

für native Typen entspricht die Default Initialization einer Value Initialization mit 0. Spricht nicht für die Sprache, beruhigt dich aber hoffentlich. Frohes Neues!

Ist doch eine gute Sache, wenn fehlende explizite Initialisierung einheitlich zur 0-Initialisierung wird. Eine Verlässliche Regel ohne Überraschungen.
Oder hast du das anders gemeint?

[Krishty]

Value Initialization == Zero Initialization gilt aber nur für native Typen. Wenn du Klassen dazwischen hast, deren K’toren Attribute nicht initialisieren, bleiben die uninitialisiert.

Code: Alles auswählen

struct Foo {
    int x;
    Foo() = default;
};

Foo foo{ }; // foo.x wird NICHT initialisiert

Das ist alles kein Problem, wenn du dich durchgängig an die Richtlinien zur Initialisierung hälst, und alles brav definierst und Standardwerte hinzufügst. Das ist aber, worauf ich hinaus wollte: Du musst bei allem, was du tust, immer obskure Richtlinien befolgen.

C hat dem gegenüber 0-Initialisierung für alles, was nicht in Initializer Lists definiert wird.

[Jonathan]

Ja, glm hat mal irgendwann aufgehört alle Vectoren mit 0 zu initialisieren, außer man macht das explizit. Stand auch irgendwo im Changelog, aber wenn man halt 20 Versionen überspringt (weil sich immer Kleinigkeiten ändern, die mich nicht betreffen) übersieht man das sehr sehr leicht. Ich durfte dann erstmal herausfinden, warum meine Projekte auf einmal alle Random crashen, dann herausfinden, dass es an der neuen glm Version lag, dann herausfinden, dass es an der geänderten Initialisierung lag und dann in meiner kompletten Codebase absolut alle Initialisierungen von allen glm Klassen doppelt überprüfen, weil auch nach Tagen des Suchens immer noch irgendwo manchmal irgendwas explodiert ist.

Das war ein totaler Riesenspaß...

[Krishty]

Ich bin total für uninitialisierten Speicher und uninitialisierte Variablen, so lange das umgebende Regelwerk halt einfach ist. Ist es in C++ aber nicht