Vortrag über Ideen für eine neue Sprache für Spieleentwickler [youtube]



  • kkaw schrieb:

    Dass Dir die Jetpilot-Analogie negativ aufgefallen ist, finde ich lustig. Hätte nach Deiner allergischen Reaktion bzgl. Maßnahmen gegen Memory Safety Bugs (à la "ich brauche sowas nicht") eher erwartet, dass Du Dich als Jetpiloten siehst, der weiß, was er tut. 😉

    Warum sollte jemand in C++ "Memory Safety Bugs" zu haben?
    Seit mindestens 2006 ist bekannt, daß das totaler Unfug ist. Nicht mehr als ein Ammenmärchen.

    Logischerweise sind die Schlussfolgerungen, die allein darauf aufbauen, ebenso hirnverbrannter Mist.



  • volkard schrieb:

    Warum sollte jemand in C++ "Memory Safety Bugs" zu haben?
    Seit mindestens 2006 ist bekannt, daß das totaler Unfug ist. Nicht mehr als ein Ammenmärchen.

    Logischerweise sind die Schlussfolgerungen, die allein darauf aufbauen, ebenso hirnverbrannter Mist

    Sorry, da ist bei mir der Troll-Detektor angesprungen. Wenn Du an einer sachlichen Diskussion interessiert bist, dann könntest Du mir ja mal verraten, ob du dich mit 2006 auf etwas konkretes beziehst, und deine Position hier in weniger polemischen Tönen darlegen.

    Hier in diesem Thread bin ich eigentlich daran interessiert, wie die Ideen des Vortragenden ankommen, weil ich festgestellt habe, dass Jon B. bei mir zunächst einen tendenziell negativen Eindruck bzgl. seiner "C++ Fähigkeiten" hinterlassen hat. Da kommen einfach die typischen Reflexe à la "der hat RAII nicht verstanden" hoch. Das ist auch der Grund, warum ich auf seinen Erfolg hingewiesen habe. Ich wollte "Der-hat-ja-kein-Plan"-Vorurteile vorbeugen und die Diskussion in eine sachliche Richtung lenken. Ich kann von mir nicht behaupten, die Praktiken der Spieleentwickler zu kennen und zu verstehen. Mir ist aber bewusst, dass wenn man das letzte bisschen Performance rauskitzeln will, Code tendentiell schlechter aussieht, ob man nun C++ Mittel zur Verfügung hat und effizient einzusetzen weiß oder nicht. Andererseits gibt es auch Leute, die in den Mitteln, die C++ zur Verfügung stellt, mehr Overhead sehen, als tatsächlich vorhanden ist.

    Wir können uns aber auch gerne stattdessen über die "Nichtexistenz" von Speichersicherheitsfehlern in C/C++ Software unterhalten und/oder warum so viele außer Dir, deren Software bei diversen Pawn-to-Own Wettbewerben oder Bug Bounties auf dem Prüfstand steht, es einfach nicht "gebacken" bekommen und so viel dümmer als Du sein müssen. Weißt Du, das ist so eine Haltung, die bei Dir durchscheint, die ich nicht ganz ernst nehmen kann.

    Vielleicht schnappst Du mal frische Luft bei einem schönen Sonntagsspaziergang und schaltest von einer Bi-Level-Wahrnehmung auf etwas mit mehr Abstufungen um.



  • kkaw schrieb:

    Speichersicherheitsfehlern in C/C++ Software

    Alles klar. 😃



  • Die meisten Spiele benutzen doch sowieso für alles Pooling um Heap Fragmentation zu reduzieren.



  • Ich faende fuer Spiele eine Sprache echt super, die wie ein etwas schlankeres C++ ist, aber von der exakten Speicherverteilung abstrahiert, also z.B. der Compiler reserve aufruft, Speicherallokationen vom Heap auf den Stack verschieben kann, gleichzeitig alloziierte und freigegebene Objekte als Block reservieren, pool-allocator fuer haeufig generierte Objekte erstellt und nacheinamder benutzte Daten in aehnliche Speicherregionen packt.



  • Was hat das mit "designing a programming language for games" zu tun? Der blubbert nur Buzzwords vor sich hin und macht ein paar (schwachsinnige) Syntaxvorschläge:

    std::unique_ptr<T[]> p;
    //wird zu
    T *! p;
    
    std::vector<T> v;
    //wird zu
    T v[];
    

    usw.

    Ungefähr 85 mal sagt er "85% solution".

    Wo kommen solche Leute immer her?



  • TyRoXx schrieb:

    Syntaxvorschläge:

    std::unique_ptr<T[]> p;
    //wird zu
    T *! p;
    
    std::vector<T> v;
    //wird zu
    T v[];
    

    usw.

    Ich habe es eher so verstanden:

    unique_ptr<T>    ->  T*!
    unique_ptr<T[]>  ->  T[]!   // Mit Range-Checking im Debug-Modus
    

    wobei er das nicht wirklich geschrieben hat. Geschrieben hat er immer unique_ptr<T>* mit dem Stern am Ende. Erst dachte ich noch, dass das ein Tippfehler ist. Aber es taucht überall auf und zieht sich bis ganz zum Schluss durch, ohne dass ihm das beim Vortragen auffällt. Für mich ist das ein ganz großes Warnzeichen dafür, dass er C++ doch nicht so gut kennt, wie er es zu kennen glaubt. Seine extreme Abneigung gegenüber RAII macht mich auch skeptisch, aber er hat immerhin irgendwo bei ab ca 1:10:00 doch noch einen validen Punkt (siehe übernächsten Absatz).

    Ich kaufe ihm auch nicht ab, dass T*! eventuell besser optimiert werden kann, es zu besseren Warnungen führen soll (der Vorteil von unique_ptr ist ja, dass es nicht kopierbar ist, statt dass der Compiler nur eine Warnung ausgibt), oder dass so etwas wie unique_ptr zwingend schlechter zu debuggen ist. Und für unique_ptr müssen wir auch nicht 100 Headerdateien inkludieren, die voll von Templates sind, (sein suggeriertes Strohmannargument gegen unique_ptr).

    Der einzige Vorteil, der da für mich übrig bleibt --- und das ist wahrscheinlich auch der Grund, warum ihr, wenn ihr nicht bis zum Schluss geguckt habt, den Vortrag scheiße findet --- ist das Feature, verschiedene Arrays in einem einzigen Block zusammenzufassen. Das könnte mindestens die Fragmentierung im Speicher reduzieren. Und im besten Fall, wenn z.B. im Gameloop ständig Speicher angefordert und wieder freigegeben wird (was aber eigentlich eher selten passieren sollte), dann wär' das eben noch einen Tick performanter, weil Speicherallozieren und Freigeben nicht kostenlos ist.

    TyRoXx schrieb:

    Wo kommen solche Leute immer her?

    Keine Ahnung. Ich schätze, auch tendenziell blinde Hühner finden mal ein Korn. Kommt mir inzwischen doch eher wie ein Cowboy/DIY-Typ vor, der doch das eine oder andere C++ Buch mal hätte lesen sollen. Dafür, dass einen das nicht zwangsläufig vom Erfolg abhält, ist er immer hin ein Beweisstück.

    volkard schrieb:

    kkaw schrieb:

    Speichersicherheitsfehlern in C/C++ Software

    Alles klar. 😃

    Ja, in der Hinsicht kann ich nämlich C und C++ Software über einen Kamm scheren. C++ hilft Dir, Speicherlecks und Double-Frees per RAII zu vermeiden. Es hilft Dir aber nicht, Use-After-Free-Fehler zu vermeiden. Dass man einen ungültigen Zeiger, Iterator oder eine Referenz hat, die man sich von anderen "besitzenden Typen" quasi "ausgeliehen" hat, kann vorkommen. Und es kommt vor. Und wenn es vorkommt, ist es ein Versehen oder ein Designfehler. Und Menschen machen fehler.

    Habe den Eindruck, als würdest Du mich in eine Schublade stecken, in die ich nicht hinein gehöre, als würdest Du mich als Element der "Outgroup" bzgl. C++ sehen. Das ist eine prima Voraussetzung für Vorurteile und eine Ausrede, nicht nachdenken und sich hinterfragen zu müssen. Ich wär hier nicht unterwegs, wenn ich C++ scheiße finden würde. Ich wär hier nicht unterwegs, wenn ich nicht mit Hilfe von C++ meine Brötchen verdienen würde, so mit allem Zipp und Zapp (sprich "modern C++"). Wenn Du es aber für nötig hältst, wegen meiner Verwendung von "C/C++" nichts substantielles beizusteuern, obwohl Du beim aufmerksamen Lesen hättest drauf kommen müssen, wie ich zu C++ stehe, dann Frage ich mich echt, mit was für einem Fanatiker ich es hier zu tun habe. (Und es ist echt schade, dass ich mich genötigt sehe, Dir erst mein Verhältnis zu C++ zu erklären, um von Dir ernst(er) genommen zu werden). Du hast hier im Thread absolut gar nichts Substantielles beigetragen. (Aussagen in der Richtung "Du und der vortragende seid doof" sind nicht substantiell. Das ist Kinderkacke). Und bzgl des Speichersicherheitsthemas kommt bei Dir nur die Haltung rüber "ich mache diese Fehler nicht" (was ich Dir glaube, ich stolpere darüber auch relativ selten), lässt Dich dann aber zu extremen Aussagen hinreißen, die mit der Realität einfach nicht korrelieren, siehe z.B. deinen "2006"-Kommentar.

    Ich weiß, Du bist kein dummer Mensch. Aber mit dem Schubladen-basierten Schwarz/Weiß-Denken à la "Haha, Du hast 'C/C++' gesagt, kannst also keine Ahnung haben" ist keinem geholfen. Es lässt Dich nur schlecht aussehen.

    Och Leute, ich bin echt ein bisschen enttäuscht von Euch. Man kann hier anscheinend keine kontroversen Themen diskutieren. Ich sehe hier keine differentierten Aussagen. Nur Schwarz/Weiß-Denken.



  • Der einzige Vorteil, der da für mich übrig bleibt --- und das ist wahrscheinlich auch der Grund, warum ihr, wenn ihr nicht bis zum Schluss geguckt habt, den Vortrag scheiße findet --- ist das Feature, verschiedene Arrays in einem einzigen Block zusammenzufassen. Das könnte mindestens die Fragmentierung im Speicher reduzieren. Und im besten Fall, wenn z.B. im Gameloop ständig Speicher angefordert und wieder freigegeben wird (was aber eigentlich eher selten passieren sollte), dann wär' das eben noch einen Tick performanter, weil Speicherallozieren und Freigeben nicht kostenlos ist.

    Kann man doch in C++ auch machen. Muss nicht in den Sprachkern.



  • kkaw schrieb:

    volkard schrieb:

    kkaw schrieb:

    Speichersicherheitsfehlern in C/C++ Software

    Alles klar. 😃

    Ja, in der Hinsicht kann ich nämlich C und C++ Software über einen Kamm scheren. C++ hilft Dir, Speicherlecks und Double-Frees per RAII zu vermeiden. Es hilft Dir aber nicht, Use-After-Free-Fehler zu vermeiden. Dass man einen ungültigen Zeiger, Iterator oder eine Referenz hat, die man sich von anderen "besitzenden Typen" quasi "ausgeliehen" hat, kann vorkommen. Und es kommt vor. Und wenn es vorkommt, ist es ein Versehen oder ein Designfehler. Und Menschen machen fehler.

    Ich vergaß: Für Iteratoren gibt's ja noch den einen oder anderen Debugmodus einer Standardbibliotheksimplementierung. Leider ist das im Fall von libstdc++ extram langsam alles. Für unique_ptr würde ich mir etwas ähnliches wünschen. unique_ptr<T>::pointer könnte im Debugmodus etwas sein, was mir get() zurück gibt und womit ich dann User-after-Free-Fehler zur Laufzeit abfangen kann. Dann fehlen im Prinzip noch "Referenz-Proxies" für Container. Vielleicht macht auch etwas in dieser Richtung für einen Debugmodus Sinn. Leufzeitchecks im Debugmodus sind besser als gar nichts. Sie dürfen das Programm nur nicht zu langsam machen.



  • kkaw schrieb:

    Der einzige Vorteil, der da für mich übrig bleibt --- und das ist wahrscheinlich auch der Grund, warum ihr, wenn ihr nicht bis zum Schluss geguckt habt, den Vortrag scheiße findet --- ist das Feature, verschiedene Arrays in einem einzigen Block zusammenzufassen. Das könnte mindestens die Fragmentierung im Speicher reduzieren. Und im besten Fall, wenn z.B. im Gameloop ständig Speicher angefordert und wieder freigegeben wird (was aber eigentlich eher selten passieren sollte), dann wär' das eben noch einen Tick performanter, weil Speicherallozieren und Freigeben nicht kostenlos ist.

    Das man kann es bestimmt in C++ selber bauen. Hat er erläutert, warum Templates und Makros nicht genügen und man deswegen unbedingt obskure Spracherweiterungen für 0,1%-Randprobleme braucht?



  • Ethon schrieb:

    [...]verschiedene Arrays in einem einzigen Block zusammenzufassen[...]

    Kann man doch in C++ auch machen. Muss nicht in den Sprachkern.

    Ja. Ich bin mir auch sicher, dass man da eine halbwegs generische Lösung für bauen kann, so dass man nicht zig Destruktoren und co immer wieder ähnlich implementieren muss (was der Vortragende mit dem Ausfüllen von Steuerformularen vergleicht). Aber das würde C++ Kenntnisse voraussetzen 😉 Nichtsdestotrotz könnte wird das wahrscheinlich in der Verwendung syntaktisch nicht besonders hübsch aussehen wird. Mit einer besseren "Metaprogrammierunterstützung" könnte sich das aber ändern. Das ist Dein Einsatz: Zeig uns, wie du es in D machen würdest. 🙂

    Oder man setzt auf Code-Generatoren, die dann die Verwendung generierter structs mit solchen Speicherlayoutoptimierungstricks dann schön aussehen lassen.



  • Es geht darum ein großes Array zu allozieren in dem mehrere Arrays verschiedener Typen zusammengefasst werden?

    Würde ich (ohne weiter darüber nachgedacht zu haben) so machen:

    memory_pool pool("1m");
    destructing_ptr<int> ints = pool.alloc<int>(10);
    destructing_ptr<std::string> strings = pool.alloc<std::string>(10);
    destructing_ptr<float> floats = pool.alloc<float>(10);
    

    Wobei ein destructing_ptr in seinem Destruktor alle Objekte in seinem Speicherbereich zerstört und den Speicher an den Pool zurückgibt.



  • template <class ...T>
    struct dynamic_array_sequence
    {
    	dynamic_array_sequence() noexcept;
    
    	explicit dynamic_array_sequence(std::array<std::size_t, sizeof...(T)> sizes);
    
    	template <class ...SizedRanges>
    	explicit dynamic_array_sequence(SizesRanges... &&ranges);
    
    	~dynamic_array_sequence();
    	dynamic_array_sequence(dynamic_array_sequence &&) noexcept;
    	dynamic_array_sequence &operator = (dynamic_array_sequence &&) noexcept;
    	dynamic_array_sequence(dynamic_array_sequence const &);
    	dynamic_array_sequence &operator = (dynamic_array_sequence const &);
    
    	template <std::size_t Index>
    	boost::iterator_range<parameter_pack_nth_t<Index, T...>> get();
    
    	template <std::size_t Index>
    	boost::iterator_range<parameter_pack_nth_t<Index, T...> const> get() const;
    
    private:
    
    	std::tuple<T *...> beginnings; //der erste Zeiger ist der Beginn des dynamischen Speicherblocks, die anderen zeigen hinein
    	std::size_t last_size;
    };
    
    int main()
    {
    	dynamic_array_sequence<float, int> mesh(std::array<std::size_t, 2>{10, 20});
    	boost::range::fill(mesh.get<0>(), 0.0f);
    }
    

    (ungetestet)
    Viel besser würde es ein Sprach-Feature auch nicht hinbekommen.

    Vergesst dabei aber nicht, dass das eine Mikrooptimierung ist. Das macht bisher keiner so generisch, weil es sich nicht lohnt.

    Wenn der Compiler beim Optimieren automatisch std::vector<T>... wie dynamic_array_sequence<T...> erzeugen würde, wenn es das Verhalten nicht ändert, wäre das natürlich schön.



  • kkaw schrieb:

    Seine extreme Abneigung gegenüber RAII macht mich auch skeptisch

    Er sagt, dass es viel zu viel Aufwand ist, jedesmal eine Klasse zu schreiben, mit Kopierkonstruktor und Destruktor und dann auch noch aus Geschwindigkeitsgruenden einen move-Constructor hinzuzufuegen.
    Er scheint aber nicht zu wissen, dass die Konstruktoren oft automatisch generiert werden und der Kopierkonstruktor oft gar nicht gebraucht wird und der Move-konsturktor oft deutlich einfacher zu schreiben ist (kopieren und auf 0 setzen).



  • kkaw schrieb:

    volkard schrieb:

    kkaw schrieb:

    Speichersicherheitsfehlern in C/C++ Software

    Alles klar. 😃

    Ja, in der Hinsicht kann ich nämlich C und C++ Software über einen Kamm scheren. C++ hilft Dir, Speicherlecks und Double-Frees per RAII zu vermeiden. Es hilft Dir aber nicht, Use-After-Free-Fehler zu vermeiden.

    Doch, klar.
    Laß es einfach sein, über C++ zu salbadern. Die ganzen Probleme, die Du siehst, sind gelöst.

    kkaw schrieb:

    Habe den Eindruck, als würdest Du mich in eine Schublade stecken, in die ich nicht hinein gehöre, als würdest Du mich als Element der "Outgroup" bzgl. C++ sehen.

    Offenbar kannste so wenig C++ wie der Videofilmer.

    kkaw schrieb:

    Ich wär hier nicht unterwegs, wenn ich nicht mit Hilfe von C++ meine Brötchen verdienen würde, so mit allem Zipp und Zapp (sprich "modern C++").

    Und WIE machst Du use-after-free-Fehler? Der Destruktor ruft free auf. Danach ist das Objekt WEG.

    kkaw schrieb:

    Wenn Du es aber für nötig hältst, wegen meiner Verwendung von "C/C++" nichts substantielles beizusteuern, obwohl Du beim aufmerksamen Lesen hättest drauf kommen müssen, wie ich zu C++ stehe, dann Frage ich mich echt, mit was für einem Fanatiker ich es hier zu tun habe.

    Sorry, Du bist hier der Fanatiker.

    kkaw schrieb:

    (Und es ist echt schade, dass ich mich genötigt sehe, Dir erst mein Verhältnis zu C++ zu erklären, um von Dir ernst(er) genommen zu werden).

    Das ist durch.

    kkaw schrieb:

    Du hast hier im Thread absolut gar nichts Substantielles beigetragen.

    Doch, ich hab Dich aufgedeckt.

    kkaw schrieb:

    (Aussagen in der Richtung "Du und der vortragende seid doof" sind nicht substantiell. Das ist Kinderkacke).

    Kritikverbot bedeutet nur, daß Ihr Euch mit Verschwörungstheorien selber überbietet, sorry.

    kkaw schrieb:

    Und bzgl des Speichersicherheitsthemas kommt bei Dir nur die Haltung rüber "ich mache diese Fehler nicht" (was ich Dir glaube, ich stolpere darüber auch relativ selten), lässt Dich dann aber zu extremen Aussagen hinreißen, die mit der Realität einfach nicht korrelieren, siehe z.B. deinen "2006"-Kommentar.

    Es ist aber so.
    2006 http://www.c-plusplus.net/forum/158841-42

    kkaw schrieb:

    Ich weiß, Du bist kein dummer Mensch. Aber mit dem Schubladen-basierten Schwarz/Weiß-Denken à la "Haha, Du hast 'C/C++' gesagt, kannst also keine Ahnung haben" ist keinem geholfen. Es lässt Dich nur schlecht aussehen.

    Ein Mann kann soo viel Scheiße labern, daß 100 Wissenschaftler es rein zeitlich nicht packen würden, ihn zu widerlegen. Und welchen Zweck hätte es? Du streitest ja eh alles ab. C++ wirste nicht mehr lernen.

    kkaw schrieb:

    Och Leute, ich bin echt ein bisschen enttäuscht von Euch. Man kann hier anscheinend keine kontroversen Themen diskutieren. Ich sehe hier keine differentierten Aussagen. Nur Schwarz/Weiß-Denken.

    Eigentlich haben wie Dir lange genug zugeschaut, oder? Das war sehr sehr lange. Erst in diesem Thread fange ich an, "substanziell" zu werden, indem ich Deine Grundthesen von der Unberherrschbarkeit von C++ bestreite. Die sind halt in allen Punkten falsch und Du suchst meiner Ansicht nach nach Lösungen für nichtexistierende eingebildete Probleme.

    C++ ist ehrlich anders als C. Es ist ganz großer Unfug, die Probleme von C beheben zu wollen, die in C++ längst behoben sind. Ganz einfach mit RAII und möglichst lokalen Variablen ist man doch schon fertig, oder? Ok, Regel der großen 3/5 und ein wenig Exceptionsicherheit dazu.

    Wie hattest Du bei dem unique_ptr nochmal es geschafft, use-after-free zu machen? Auch das mag mir nicht natürlich erscheinen.



  • Mal eine ganz andere Sache: Bringt das mit den zusammenhaengenden Speicherbloecken ausser bei ganz kleinen Meshes ueberhaupt etwas? Soweit ich weiss, hat man ab Page-grossen Bloecken (also meistens 4 kb) keine Geschwindigkeitsvorteile durch erhoehte Lokalitaet mehr, aber im Gegenzug viel mehr Probleme mit externer Fragmentierung, weil kleine Luecken nicht mehr genutzt werden.

    volkard schrieb:

    Wie hattest Du bei dem unique_ptr nochmal es geschafft, use-after-free zu machen? Auch das mag mir nicht natürlich erscheinen.

    Indem man noch irgendwo pointer herumliegen hat, die man beim Zerstoeren des Objektes nicht geloescht hat.
    Z.B. wenn man eine hirarchische Baumstruktur hat, ein Objekt bearbeitet und dabei den parent loescht. Das Problem laesst sich loesen, insgesamt sind aber dangling pointer eine haefige Fehlerquelle, insbesondere wenn der Code ueber die Zeit waechst.





  • kkaw schrieb:

    Ich kannte den Typen nicht. Er ist aber wohl ein schlauer Kerl mit Erfahrungen im Spieleentwicklergeschäft. Und statt bei Sprachen wie C, C++ zu bleiben, oder auf D, Go oder Rust zu wechseln, hat er sich mal ein paar Gedanken gemacht, wie man speziell Spieleentwicklern das Leben leichter machen könnte.

    Ich habe das Video noch nicht gesehen, aber da ich gesehen habe, dass Du direkt verbal einen verpasst bekommen hast, möchte ich Dir für den Link erstmal danken. Ich habe ihn mir kopiert und werde ihn mir die Tage anschauen.

    Selbst wenn der Typ keinen Plan hat, kann ich mir daraus entsprechend das umgekehrte herausnehmen und für mich ist es durchaus interessant zu sehen, welche Gedanken sich andere zu Programmiersprachen machen und zu welchen Schlussfolgerungen sie kommen.

    Also: Vielen Dank. 🙂



  • Xin schrieb:

    Selbst wenn der Typ keinen Plan hat, kann ich mir daraus entsprechend das umgekehrte herausnehmen und für mich ist es durchaus interessant zu sehen, welche Gedanken sich andere zu Programmiersprachen machen und zu welchen Schlussfolgerungen sie kommen.

    Das dachte ich auch.

    volkard, wir können anscheinend nicht miteinander. Ich seh' da jetzt keinen Einsatz von Dir, der eine differentiertere Antwort meinerseits rechtfertigt. Und natürlich sprichst Du mir auch Kompetenzen ab. Das wundert mich jetzt auch nicht mehr. Du willst mich hier als Rust-Spammer und C++ Basher entlarvt haben. Dann schau doch nochmal nach, was ich hier und sonst wo so verzapft habe. Meine anderen Aliase sind "Sebastian Pizer" und "krümelkacker". Ich logge mich nur inzwischen ungern auf Seiten mit Passwort ein, die kein HTTPS bieten, auch wenn das Passwort kein besonders wichtiges ist. Das ist so ein neuer Tick von mir.



  • volkard schrieb:

    C++ ist ehrlich anders als C.

    Ja genau das meine ich. Du denkst ich bin ein "C-in-C++" Programmierer oder so ähnlich, der von RAII und was man damit machen kann, keine Ahnung hat etc etc etc. Wahnsinnige Kognitionsleistung von Dir ...

    Nee, ich habe mit use-after-free auch keine Probleme. Aber ich bilde mir nicht ein, alle Anwendungsdomänen zu überblicken. Gerade bei so GUI Zeugs, könnte das gut vorkommen, wenn man nicht überall shared_ptr benutzen will/kann. Eigentlich habe ich es doch schon gesagt. Wenn man sich Zeiger/Referenzen/Iteratoren auf Elemente von besitzenden Containern unter der Annahme "ausleiht", dass er lang genug leben wird, es dann aber doch nicht tut, weil man irgend etwas nicht beachtet hat. Ja, dann hast du einen use-after-free. Wenn Du die Menge der Programme, die Du schreibst, auf das einschränken kannst, wo so ein "Ausleihen" nicht oder nur sehr kurz stattfindet, dann bist Du wie ich in der glücklichen Lage, keine use-after-free Fehler zu bauen. Gratuliere.


Anmelden zum Antworten