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

[Marthog]

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.

[TyRoXx]

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?

[kkaw]

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.

[Ethon]

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]

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.

[TyRoXx]

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?

[kkaw]

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.

[Ethon]

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.

[TyRoXx]

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.

[Marthog]

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

[volkard]

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.

[Marthog]

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.

[Gast]

http://www.c-plusplus.net/forum/328097

[Xin]

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.

[kkaw]

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.

[kkaw]

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.

[hustbaer]

volkard schrieb:

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

Das geht so einfach nur in Bilderbuchbeispielen, wo immer alles "unique ownership" ist und es nie ausgeborgte, nicht-besitzende Zeiger oder Referenzen gibt.
Sobald es die gibt, kann man Mist bauen.
Heisst: das Objekt das die Resource besitzt mag zwar weg sein, aber das heisst noch lange nicht dass keiner mehr nen Zeiger bzw. ne Referenz mehr darauf hat.
D.h. du kannst "use after free" der Resource gegen "use after free" des RAII-Resourcen-Wrappers eintauschen. Aber verhindern kannst du es so nicht.

Gerade da hier im Forum (und auch andrerorts) immer rumgeheult wird wie phöse doch shared_ptr ist, und dass man ihn ja fast nie braucht...
Und wenn man versucht so weit wie möglich auf shared_ptr zu verzichten dauert es nicht lange bis man sich wieder in den Fuss schiesst.

Was u.A. ein Grund ist warum ich shared_ptr sehr freizügig verwende. Weil mir die Probleme die man durch zu viel shared_ptr bekommt lieber sind als die die man durch zu wenig shared_ptr bekommt.

[Kellerautomat]

Ich denke, der Typ hat im grossen und ganzen Recht. Zwei Hauptpunkte, in denen ich absolut nicht zustimme: RAII und Funktionsparameter
RAII ist einfach praktisch, auch ohne Exceptions (die ich im Uebrigen auch fuer Mist halte). Ich will einfach kein free/dealloc/etc hinschreiben muessen.
Funktionen sollten nicht mehr als 4 Parameter haben. Die Beispiele mit 10+ Parametern sind einfach Mist. Named Parameters sind aber natuerlich trotzdem nett.
Ansonsten hat er meine volle Zustimmung, wenn ich nichts vergessen habe.

[volkard]

kkaw schrieb:

Meine anderen Aliase sind "Sebastian Pizer" und "krümelkacker".

Das sind allerdings große Namen, denen ich keine Kompetenz abspreche.

kkaw schrieb:

Nee, ich habe mit use-after-free auch keine Probleme. Aber ich bilde mir nicht ein, alle Anwendungsdomänen zu überblicken.

Hmm. Da gibt es dann noch die Leute, die voller Menschenliebe für andere Sachen erfinden, die sie selber nicht brauchen, wie sicheres Spielwerkzeug, Lehrsprachen oder Religionen.

Hmm, wo hatte ich mal Probleme mit der Löschverantwortung? Vor fast 15 Jahren, hab da simulierte Netzwerkpakete zeitversetzt geschickt, also der Sender musste sie loslassen. Und die Senke war vorher nicht klar, im Laufe der Verarbeitung konnten sie sich auch mal ändern oder gar duplizieren. War natürlich lösbar, auch wenn ich es heute anders machen würde.

kkaw schrieb:

Gerade bei so GUI Zeugs, könnte das gut vorkommen, wenn man nicht überall shared_ptr benutzen will/kann.

Kann sein. Ich schreibe nicht viel Oberflächencode. Bisher keine Probleme. Schlimmstenfalls verknüpft man GUI-Elelente eben mit shared_ptrs, wie Du es großzügig machst.

kkaw schrieb:

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

Du stellst Dich anscheinend als Verteidiger der "C-in-C++"-Programmierer hin, sagst die typischen C-Fehler seien in C++ voll normal. Ist wohl klar, wie das wirkt.

[Kellerautomat]

Ich moechte nochmal etwas genauer auf die einzelnen Punkte eingehen.

RAII: Was der Typ offensichtlich nicht rafft, ist dass RAII auch ohne Exceptions super nuetzlich ist. Dass RAII Wrapper nervig zu schreiben sind, ist denke ich mal kein Geheimnis und finde ich auch stoerend. Man kann aber mit einer Helfer-Klasse Abhilfe schaffen (ich vermute dass scoped_resource aus C++14/17 sowas ist?)

Exceptions: Vermutlich eine der schlechtesten Erfindungen in der Geschichte der Programmiersprachen. Es gibt so ziemlich keinen Fall, in dem ich eine Exception verwenden wuerde. Out of bounds? Da soll das Programm crashen, weil das ein Bug ist. File konnte nicht geoeffnet werden? Das ist doch vollkommen erwartet. Zu wenig Speicher? Error-Message & terminieren. Es gibt einfach keine Faelle, in denen Exceptions irgendwie sinnvoll sind. Halt, doch. Da war doch was mit Konstruktoren. Hm, vielleicht einfach Konstruktoren entfernen und Funktionen bereitstellen? Koennte klappen. Oder einfach nix im Konstruktor machen, was fehlschlagen koennte. Hey, das klingt doch gut.

Kurzform fuer unique_ptr? Immer her damit! Aber nicht so. unique_ptr in der stdlib ist gut so, aber man kann ja auch Klassen erlauben, Typ-Konstruktoren zu erfinden. Ich nenne es mal custom declarators. Also T! -> unique_ptr<T> und T? -> optional<T>. Dass der Compiler das benutzen koennte, um schnelleren Code zu erzeugen, oder fuer bessere Fehlermeldungen ist doch Schwachsinn. C++ ist einfach zu kompliziert. In einer simplen Sprache gibts das Problem gar nicht, behaupte ich einfach mal. Dass der Pointer-Typ ein Attribut vom T sein sollte und nicht umgekehrt, da hat er Recht.

Joint Arrays: Joa, das finde ich gut. In Spielen muss man dauernd Daten auf die GPU uploaden, da waere sowas ultra praktisch. In Kombination mit Introspection koennte man auch vermutlich recht schoen die erforderlichen OpenGL/DX Calls automatisch generieren. Einzig was mich daran stoert in seiner praesentierten Form, ist dass man ein "Hauptattribut" waehlen muss, das mit allen anderen gejoined wird. Das ist Syntax-maessig einfach seltsam.

Named Parameters: Sicherlich praktisch, aber meiner Meinung nach sollte keine Funktion ueber 4 Parameter haben. 4 ist hierbei ein Hard Limit. Exakt 4, nicht 5. Oft kann man Parameter recht schoen zusammenfassen. Ein void*/size_t Paar in eine MemoryRegion oder so. Statt begin/end Iterator eine Range. Und so weiter. Ausserdem sollte man nicht ausschliesslich Named Parameters haben. Bei einem sin() moechte ich da keinen Namen hinschreiben muessen. Was waere ueberhaupt ein sinnvoller Name? x? value? Macht einfach keinen Sinn.

Fragmentierung: Halte ich fuer kompletten Bullshit. Das Problem ist, dass dynamische Arrays heute nicht die richtigen Allokationsstrategien verwenden. Wenn ich einen vector habe, dann ist erwartet, dass da eine Menge Objekte reinkommen. Und wenn ich eine Menge Objekte habe, die linear im Speicher liegen, dann kann ich auch einfach nur ganze Pages allozieren, da brauch ich keinen fancy Allokator mit Free-Lists, Buddy System und was weiss der Teufel. Die paar Bytes am Ende des Vektors die ungenutzt sind interessieren Keinen, der Vektor ueberalloziert doch sowieso.
Will ich viele kleine Vektoren, dann sieht die Sache natuerlich etwas anders aus, aber das ist dann auch ein speziellerer Use-Case. Vielleicht zusaetzlich eine small_vector Klasse oder sowas.

shared_ptr: Hab ich persoenlich noch nie gebraucht, kann also nicht nachvollziehen was das bringen soll. Und natuerlich kann man mit RAII use-after-free Fehler bauen. Das verhindert man am besten, indem man ein API ordentlich designed. Aber unmoeglich ist es dadurch natuerlich nicht.

Hab bestimmt was vergessen, werde aber das Video zuhause nochmal ueberfliegen.

Gruesse
Der Kellerautomat