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



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

    Das Video ist auf englisch und leider recht lang. Der Vortrag geht etwa 90 Minuten und danach kommt nochmal ne knappe halbe Stunde Q&A.

    Was den Vortrag interessant macht, ist die Perspektive eines erfahrenen Spieleentwicklers, der RAII und Ausnahmen sehr kritisch sieht. Nach etwa 'ner halben Stunde Einführung und allgemeineren Prinzipien und Zielen bekommt man dann nach und nach relativ Zeiger-lastigen C++ Code zu sehen, wo ich mir es irgendwie nicht verkneifen konnte, zu denken "Der hat doch keine Ahnung von C++". Allerdings geht's dann weiter in Richtung "data oriented design", wo unterschiedliche Arrays im selben Speicherblock zwecks Datenlokalität abgelegt werden sollen. Und das sieht dann leider relativ hässlich in C++ aus, egal ob man std::vector oder std:unique_ptr irgendwo benutzt oder nicht.

    Im Wesentlichen argumentiert er für "owning pointers", die im Sprachkern enthalten sein sollen und damit die "Debugging Experience" (bzgl double-free und use-after-free Bugs) und Compiler Fehlermeldungen und Warnungen verbessern würden und low-levelige Speicherlayoutoptierungen leichter erlauben. Andere nicht-Speicher-Resourcen seien nicht so wichtig, dass man dafür eine generelle Lösung à la RAII bräuchte. Und Ausnahmen mag er auch nicht.

    https://www.youtube.com/watch?v=TH9VCN6UkyQ



  • {quote]Er ist aber wohl ein schlauer Kerl mit Erfahrungen im Spieleentwicklergeschäft.[/quote]
    Das ist bekanntermaßen ain Anti-Argument. Siehe Carmack und seinen jahrzehntelangen verbitterten Kampf gegen C++ und dann doch sein Einsehen. Siehe die gesamte Gamecoder-Gemeinde und die gequirlte Scheiße, sie sie in ihre Compiler steckt.

    Ich schaue mir den Kasper mal an und übersetze seine Thesen:

    -03:41: Ich bin ein Nube oder will Nubes schützen.

    -05:19 Ich gehe jeden Tag zur Arbeit und kanns einfach nicht einsehen, daß keiner was erfindet, daß ich schon da bin.

    -09:07 Ich mag einfach kein C++.

    Ab dann Geplapper.

    Laß uns doch einfach mal annehehmen, daß es keinen Königsweg zur Programmierung gibt. Du verlangst doch auch keine bessere Mathematik, damit die Schüler den Pythagoras schneller lernen und die Ingenieure bessere Brücken bauen. Du verlangs kein besseres Deutsch, damit wir mehr Literaturnobelpreise gewinnen und mehr Leute sehen, wie dumm Merkel ist.

    -um 20:00 salbadert er was über Jet-Piloten.

    -22:15 Hab keinen schnellen Rechner.

    -23:20 Will mich auch gar nicht auf Tatsachen gründen.

    Muss ich den Rest auch noch anschauen?

    edit:
    -27:56 Ich habe nicht den geringsten Schimmer, was mächtige Sprachen sind und was PHP ist.

    -30:05 Bin rein in der Gamecoders-Welt.

    -32:20 C++-Bucg gelesen aber C++ noch nicht ausprobiert.

    -33:02 Genau gar nichts verstanden.

    -34:18 Ich rede nicht über was anderes als Video-Games.
    *lach*

    -35:18 RAII gerade mal gar nicht verstanden.

    Sorry, die Dummheit tut weh. Da schau ich lieber Videos über Chemtrails.

    48:35 Shitty Code.
    51:10 Und schlecht repariert.

    52:25 MSVC6.1 hatte das schon. Dafür ist echt keine neue Sprache nötig. Außerdem kann man ihn leicht selber schreiben.
    54:00 Ebendiese wären sein Suchproblem, sind sie ja eh schon.

    kkaw schrieb:

    Dein Nick ist hiermit verbrannt. Vorher nahm ich Deine Rust-Werbung noch wahr. Indem Du dieses Video vorstellst als gut, biste durch.



  • Etwas "interessant" finden und etwas "gut" finden, sind bei mir zwei paar Schuhe. Ich bin von dem, was er erzählt nicht überzeugt. Aber ich finde es interessant, dass sich einer vor die Kamera stellt, der nicht zu dumm dazu war, ein angeblich halbwegs erfolgreiches Indi-Spiel in C++ zu schreiben und sich dann über RAII beschweren kann. Klar, ich halte es für möglich, dass ihm der Erfolg zu Kopf gestiegen ist und sich für schlauer hält, als er tatsächlich ist. Beispielsweise gibt er in der Q&A-Phase bei der Frage nach empfehlenswerten Programmierbüchern zu, nichts außer K&R gelesen zu haben. Ich bin da eher von der anderen Sorte, der Stroustrups und Meyers' Bücher verschlungen hat. Aber dass das jetzt alles totaler Blödsinn sein soll, was der Vortragende da von sich gibt, das sehe ich nicht so. Die bisher beste (kritische!) Antwort auf den Vortrag, die ich gesehen habe, ist diese hier. Sie hat meine volle Zustimmung und dürfte auch ganz nach Deinem Geschmack sein.

    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. 😉



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




Log in to reply