spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

Dumm ist leider nur, dass du erst beim kompilieren siehst.

Fehler fallen meist immer erst beim Kompilieren auf.
Bei VS wird Const Correctness und Member auch schon im Hintergrund durch die IDE überprüft.
Das Argument verstehe ich nicht.

Für saubere sichere Schnittstellen und gutes Design möchte ich für meinen Teil Const Correctness nicht mehr missen. So kann man Dinge problemlos als Referenz/Pointer herumreichen ohne Angst vor Seiteneffekten haben zu müssen und das nochmal extra irgendwo dokumentieren zu müssen. Ein bisschen Arbeit ist es, ja. Aber nicht zu viel.
"const" vergesse ich auch manchmal, bin dann allerdings glücklich wenn es direkt zu einem Fehler führt. Ab und zu vergesse ich es ohne dass es auffällt und sorgt erst später für kleine Problemchen, die sich aber zum Glück auch schnell wieder beheben lassen.
"IList<T>" ist auch wieder schreibbar und dein Punkt war ja, dass man mit "IEnumerable<T>" Schreibzugriff verhindern können soll.

Zitat von »TrommlBomml«

Naja, dass ich bin bis heute nicht überzeugt dass das die Performance-Killer sein sollen. Das hält sich doch im Nanosekundenbereich.

Es ist Tatsache, dass sie auf der CPU für Sprungvorhersage, Cache usw. das sehr sehr schlecht sind.
Nanosekunden hin oder her, sie stecken schließlich dann auch in den inneren Schleifen und entfalten ihre Wirkung an der Stelle dadurch gut.

Ich möchte an dieser Stelle nur darauf hinweisen dass diese Diskussion ein wenig abzuschweifen droht. Etwas weniger Prinzipienkampf und mehr beim Thema bleiben bitte Sonst artet das hinterher in Seitenlangen Abspaltungen aus wie es so oft der Fall ist.

Ganz ehrlich? IEnumerable ist schlecht, weil es virtual calls macht und weil es nicht zu reversen geht?
premature optimisation
Macht Euch Gedanken über Eure Algorithmen und logische Korrektheit und nicht darüber, ob eine Iteration nun ein paar Zyklen mehr oder weniger braucht. Diese Stellen waren zudem bisher so gut wie nie die Performance-Löcher in irgendeiner meiner praktischen Anwendungen. Die CPU-Killer stecken meist ganz woanders als in der Verwendung (oder nicht) eines IEnumerable-Interfaces.

Ich würde sagen am besten natürlich gar nicht. Was der Königsweg da in C++ ist, das weiß ich nicht und will mich daher am liebsten vor der Antwort drücken. Keiner der Wege scheint mir sonderlich elegant, da selbst mit Iteratoren für begin und end der Typ der internen Collection disclosed wird. Das umgeht man bei C# durch das IEnumerable, welches ja nur ausdrückt, dass es eine Menge einer unbestimmten Ordnung und Struktur ist (wo ich dots Meinung nicht teilen kann - denn es muss keine Collection intern existieren, ich kann auch per yield lauter einzelne Variablen als IEnumerable zurückgeben oder multiple verschiedene Collections mergen). Das gibt's ja aber eben nicht.

In C++ kann man die Iteratoren auch so herumreichen, dass der Typ dahinter versteckt ist.
Das "yield return" von C# geht in C++ auch, in dem man einfach einen eigene Iteratorklasse erstellt, so wie es in C# vor 2.0 auch war. (bzw. wie es jetzt im Hintergrund versteckt immer noch ist.)

Mit der Performance hast du im Prinzip schon recht, jedoch sind einige Algorithmen dadurch unmittelbar getroffen.
Zb. all die Dinge die bei C++ im "algorithm"-Header stecken wie beispielsweise "sort", sollen darunter leiden. "Reverse" ist auch ein gutes Beispiel. Wenn nur "IEnumerable<T>" zur Verfügung steht, müsste es ein sehr schlechtes Laufzeitverhalten haben. Getestet habe ich das allerdings noch nicht.
Und wenn man mit auch nur mittelgroßen Datenmengen hantiert, ist das schon von Bedeutung, wenn die Laufzeit x mal langsamer ist.

Ich habe nicht gesagt, man soll es nicht verwenden, nur man kann es aus den ganzen Gründen manchmal nicht verwenden und C++ bietet auf statische Weise fast das Gleiche und noch mehr. Meine Ursprungsaussage sollte eigentlich auch hauptsächlich sein, dass die "readonly"-Funktionalität in C++ definitiv umfassender funktioniert.

Ein yield return ist kein Iterator. Auch nicht versteckt. Das funktioniert komplett anders.

Doch, der Compiler erzeugt im Hintergrund eine von "IEnumerable<T>"(und einigen anderen Interfaces) abgeleitete private Klasse(Also im Prinzip einen "C#-Iterator").Das kann man auch selbst ganz schnell herausfinden, in dem man zb. mit dem .Net Reflector eine entsprechende Binary untersucht. Eine "yield return"-Funktion kann auch komplett manuell erstellen. Bei C# bis 1.1 und C++ notwendigerweise. "yield return" ist natürlich trotzdem praktisch.

Der Unterschied ist nur der ganz kleine, dass der Code in C# komplett umgeschrieben wird. Das lässt sich also nicht durch einen generischen Iterator lösen, sondern erfordert Compiler-Support, außer man will für jede Methode einen neuen Iterator schreiben - was natürlich unnützer Overkill ist.
Ändert aber dennoch auch nichts daran, dass außer mit einem eigenen Iterator sich nach außen in C++ nicht verstecken lässt welcher Collection-Typ intern verwendet wird. Irgendwie nicht sehr elegant, denn da muss man eben pro Klasse oder gar pro Methode einen eigenen Iterator implementieren, wenn man es nicht disclosen will. Das kann irgendwie nicht im Sinne des Erfinders sein.

Zitat von »TrommlBomml«

In meinen Fall habe ich konkret zwei Objekte. Eines verwaltet Objekte in einer Baumstruktur und dient zur Aktualisierung der Daten, in diesem Fall ein SceneGraph. Der SceneGraph besitzt diese ganzen Objekte und aktualisiert diese. Es ist aber nicht seine Aufgabe, die Objekte auch zu rendern. Dafür gibt es das SceneRenderer-Interface, der einen SceneGraph kennt und seine Objekte sequentiell zum Rendern erhalten muss, um ggf. optimierungen in der Zeichenreihenfolge etc. vorzunehmen. Es ist ja wohl nicht gut, wenn der SceneGraph auch rendert. Und das sortieren ist abhängig vom Renderverfahren (Deferred, Forward, verschiedene Qualitätsabstufungen, mit Ohne Postprocessing, etc.) und somit ist diese Aufgabe extra in einem Interface angebildet. Daher muss SceneRenderer irgendwie die Objekte aus dem SceneGraphen erhalten und verarbeiten.

Visitor Pattern: Schick den SceneRenderer durch den SceneGraph und jeder Node, der eine visuelle Ausgabe haben soll, trägt entsprechende Visual Objekte ein. Und schon ist die ganze Iterationslogik im SceneGraph gekapselt, wo sie auch hingehört. Rendering und Scenegraph sind wunderschön entkoppelt, den Renderer braucht es nicht zu interessieren, wie genau der SceneGraph für diesen konkreten Fall traversiert werden muss und den SceneGraph braucht es nicht zu interessieren, in was für eine Struktur der Renderer seine Visuals speichert; nirgendo muss etwas unnötig kopiert, irgendwelche Iteratoren herumgereicht (IEnumerable ist, wie gesagt, nichts anderes als eine ganz spezielle Art von Iterator) oder gar interne Container exposed werden. Hat den weiteren Vorteil, dass ein Node auch gern mehrere oder gar keine Visuals haben kann...