Hast du dir die Slides mal angeschaut? Irgendwie kam das total so rüber als hätten die wirklich Haskell genutzt.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Ja ich hab mir die Folien angeguckt und sollte man ein Support haben, dann hab ich den im UDK nicht gesehen.
Nur weil die Folien von Epic kommen, ist es nicht besser oder wahrer als andere Papers.
Was ich damit sagen will, lest das Paper mit dem Gedanken, es ist von völlig unbekannten Leuten und seit skeptisch.

Einige Daten waren falsch, einige veraltet und einige Aussagen kann ich absolut nicht beipflichten.
Wie auch schon erwähnt wurde, sind einige Vorschläge absolut unverständlich von der syntax.
Es gibt natürlich auch gute Dinge und Zahlen dich ich aus Erfahrung und anderen Papers bestätigen kann.
Nebula2.5 z.B. hat für Drakensang auch mit Objektzahlen um die 10.000 handeln müssen und entsprechend parallelisierung und schnelle Attribut mechanismen entwickelt, damit sowas noch möglich ist.
C++ ist wirklich schlecht im Bereich parallel processing ausgestattet. So gibt es zwar OpenMP für VSC++ und GCC aber das ist mehr für schleifen und ähnliche dinge und nicht für unterschiedliche parallel laufende Programmcodes, wie z.B. Netwerk und Sound. C++ wird Threads, welche dafür notwendig sind, mit der kommenden ISO hinzufügen(Ende des Jahres soll er abgeschlossen sein).
Die meisten Frameworks und Engines schreiben sich selber Klassen und Funktionen für diesen Bereich, was ja nicht im Sinne der Wiederverwendung ist.
In diesem Bereich kann man so viel machen, wie z.B. Threadpools, Priority Jobs, Atomic Operations, Scope Locks und so weiter.
Polymorphy ist auch nicht gerade schnell und erst recht nicht, wenn man noch virtual functions nutzt.

"Dynamic Failure in Mainstream Languages" Ist auch ein bisschen komisch, die Syntax sieht nach Java/C# aus und die angeführten Probleme gibt es bei C++ nicht, mit ausnahme des out of bound Problems, welches vom Memory Manager mit einer out of bound exception abgefangen wird. Man sollte dann sich eine andere Konstruktion wählen, ich würde z.B. nach der erstellung von vertice und indicies eine Prüfung machen und nicht innerhalb vom Transform, da die dann bei jedem Transform wieder passieren würde.
Was mich daran stört, ist das der Fehler ja bei der generierung von vertice und indicies aufgetreten ist und statt dort den Code Robuster zu machen, versucht man durch kostenintensive laufzeitprüfungen späteren code Robuster zu machen. Also das Beispiel ist nicht gerade gut gewählt.
Die Idee ein Mechanismus zur validierung von Werten in listen find ich aber gut.

Es wird noch ein bisschen über Exceptions geredet und wie man sie verwenden sollte, wo doch Exceptions in C++ schlechtes Foo sind.
Der Grund hierfür ist, dass Exceptions memory leaks erzeugen können und bei constructor und destructor unvorhersehbare Probleme nach sich ziehen kann.
Man soll, laut C++ ISO Konsortium z.B. nur in absoluten härtefällen eine Exception nutzen, in verbindung mit Hardware und sonnst völlig darauf verzichten.
Exceptions ins langsam und wenn eine auftritt wird der Code noch langsamer, da ein kompletter rollback im scope zufolge hat.
Man empfiehlt eigene ErrorCodes als Rückgabe von Funktionen zu verwenden.

Ich find es ein bisschen negativ zu schreiben "Garbage collection should be the only option" und kein einziges Wort darüber zu schreiben.
Denn es gibt viele verschiedene GC und einige sind gut einige sind schlecht und im Bereich von Spielen sind GC sogar schlecht, da man die Prozessorlast, die für das Aufräumen nicht eingeplant werden kann. Der Grund hierfür ist, dass der GC in Intervallen durch läuft und mal wesentlich länger braucht und mal sofort wieder in pause geht.
Refcounter und ScopePointer sind gut einplanbar und auch schneller, man muss sie nur verwenden.

SceneGraph scenegraph;
auto_ptr<Player> player=auto_ptr<Player>(new Player);
player->SetName("Hans Meiser");
scenegraph.AddNode(player);//void SceneGraph::AddNode(auto_ptr<Node> &Node);

auto_ptr ist ein teil des C++ ISO und kapselt ein pointer, wenn man ein auto_ptr varriable einer anderen zuweist, dann räumt der eine auf und setzt sich 0 und der andere räumt auf und übernimmt den neuen pointer. Sollte einem das zuviel Tipparbeit sein, dann kann man sich eine Refcounter Klasse schreiben und seine Klassen davon ableiten bzw. per Macro oder Template einbauen. Macros haben den Vorteil, dass man sich ein Constructor und Destructor spart, was bei oft genutzten Klassen sich stark auswirkt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Danke für den Text, fand ihn wie immer sehr interesannt.
Mein Kommentar oben war übrigens nicht gegen dich speziell frei dem Motto "Ey, ick habs gelesen, du nich, Keule.", sondern war schlichtweg Verwunderung, weil die Haskell-Nutzung so bei mir ankam.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos