spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Beide Lösungen erlauben es, Code zu schreiben, der vom intern verwendeten Containertyp unabhängig ist. Beide Lösungen sind imo meistens Suboptimal, da es meiner Erfahrung nach normalerweise eine bessere Lösung gibt, in der die Iteration gekapselt ist; siehe Beispiel aus meinem letzten Post...

Ich denk, die C++ vs. C# Diskussion kann man an dieser Stelle langsam abschließen, die Frage hier war immerhin eindeutig nach "C++ best practise". IEnumerable<T> entspricht dem C# Ansatz für generische Container. Aufgrund der limitierten Möglichkeiten was generische Programmierung betrifft, muss man in C# dabei zwangsweise auf dynamische Polymorphie durch Interfaces zurückgreifen. In C++ hat man mehr Freiheiten; C++ best practice für diesen Fall siehe C++ Standardbibliothek bzw. Stichwort ranges...

Die Diskussion bezüglich C# dient lediglich dem Vergleich. Ich finde es allerdings sehr traurig, wie Deine Wortwahl ausfällt. Allerdings nichts neues und nicht sehr verwunderlich.

Betrachten wir das ganze eben sprachneutral. Wir haben statischen Polymorphismus auf der einen Seite und dynamischen Polymorphismus auf der anderen Seite. Beides steht nicht in Konkurrenz zueinander, sondern ergänzt sich. Ein Vergleich macht Sinn, so lange es darum geht, die Natur dieser beiden Konzepte zu verstehen. Die Frage, was denn nun besser ist, ist dagegen völlig sinnlos. Genausogut könnte man sich drüber streiten, ob Fliegen besser ist als Autofahren...

Fakt ist, dass es in C++ statischen Polymorphismus gibt. In C++ habe ich damit nunmal gewisse Möglichkeiten, die ich in Sprachen, die gar keinen oder nur sehr eingeschränkte Formen von statischem Polymorphismus kennen, nicht habe. Gerade in modernem C++ hat statischer Polymorphismus sich als von fundamentaler Bedeutung erwiesen und taucht dort praktisch überall auf, jeder C++ Programmierer mit etwas Erfahrung wird das bestätigen. Es sollte offensichtlich sein, dass ein sinnloser Wettstreit komplementärer Konzepte im Kontext einer grundverschiedenen Sprache nicht die Antwort auf die Frage nach der best practise in C++ liefern wird, genauso wie "gut genug" und "normalerweise kein Problem" nicht die Art von Argumentation sind, über die "best practice" in der Regel abgeleitet wird...

Der Vergleich zu C# war da sehr naheliegend, da ein IEnumerable (auch wenn du dem nicht zustimmst) deutlich besser die Details versteckt als ein typedef und dieses Konzept eben leider in C++ nicht existent ist. Dass diese Aussage einem C++ Entwickler nicht hilft, das ist wohl jedem bewusst. Es ging auch dabei nur darum, dass ein schönes Konzept gesucht wurde, was diesem vielleicht nahe kommt. Wie soll man sonst sagen, was man sucht, wenn man keine Vergleichsmöglichkeit bietet?
Das Problem ist aber nicht neu und ich verlinke jetzt einfach mal ein paar Seiten, die sich mit diesem Problem praxisrelevant beschäftigt haben:
http://www.accu.org/index.php/journals/479 (gerade offline, gestern ging's)
http://stlab.adobe.com/classadobe_1_1any__iterator.html
http://thbecker.net/free_software_utilit…y_iterator.html
Da muss man auch nicht groß von statischer vs. dynamischer Polymorphie reden. Das Problem lässt sich lösen und boost findet das Thema scheinbar höchst spannend.

Die optimale Lösung wurde ja allerdings schon mehrfach vorgeschlagen - nämlich die Menge überhaupt nicht nach außen zu reichen. Ich glaube dabei sollten wir es dann wohl auch belassen, denn deine Argumentation führt mal wieder nur ins Theoretitopia und hilft letztlich auch niemandem. Dot, ohne dich angreifen zu wollen, aber etwas mehr praktischer Bezug und etwas weniger theoretische Wissenschaftlerei wäre manchmal ganz wünschenswert. Das mag dein Beruf sein, aber es... ist irgendwie auf Dauer anstrengend.

PS:

Zitat von »dot«

Genausogut könnte man sich drüber streiten, ob Fliegen besser ist als Autofahren..

Fakt: Jede Menge Science-Fiction-Filme beschäftigen sich mit fliegenden Autos.
Theorie: An der Synthese beider Konzepte muss wohl was interessantes dran sein.
Hinweis: Die Theorie lässt sich auf den Sprachvergleich übertragen.

Zitat von »BlueCobold«

Der Vergleich zu C# war da sehr naheliegend, da ein IEnumerable (auch wenn du dem nicht zustimmst) deutlich besser die Details versteckt als ein typedef und dieses Konzept eben leider in C++ nicht existent ist.

Dieses Konzept lässt sich in C++ genauso ausdrücken wie in C#, wie die von dir verlinkten Artikel ja alle wunderschön zeigen.

Zitat von »BlueCobold«

Da muss man auch nicht groß von statischer vs. dynamischer Polymorphie reden.

Doch, genau darin liegt der Unterschied der beiden Varianten und genau dort ist der Grund zu finden, wieso diese Diskussion völlig sinnfrei ist.

Zitat von »BlueCobold«

Das Problem lässt sich lösen und boost findet das Thema scheinbar höchst spannend.

Ich habe nie behauptet, dass das Problem sich nicht lösen lässt, im Gegenteil, mein Punkt war eben, dass es in C++ wesentlich mehr Lösungen für dieses Problem gibt und man für die Frage nach der best practice in C++ alle Möglichkeiten betrachten muss, die C++ bietet.

Zitat von »BlueCobold«

Dot, ohne dich angreifen zu wollen, aber etwas mehr praktischer Bezug und etwas weniger theoretische Wissenschaftlerei wäre manchmal ganz wünschenswert. Das mag dein Beruf sein, aber es... ist irgendwie auf Dauer anstrengend.

Gut, ich hab eh bereits alles dazu gesagt, was ich wichtig find. Ich möchte an dieser Stelle nur noch festhalten, dass alles, was ich hier gesagt habe, einzig und allein meiner praktischen Erfahrung entspringt, auch wenn mein Beruf offenbar etwas anderes suggeriert...


PS:

Zitat von »BlueCobold«

Zitat von »dot«

Genausogut könnte man sich drüber streiten, ob Fliegen besser ist als Autofahren..

Fakt: Jede Menge Science-Fiction-Filme beschäftigen sich mit fliegenden Autos.
Theorie: An der Synthese beider Konzepte muss wohl was interessantes dran sein.
Hinweis: Die Theorie lässt sich auf den Sprachvergleich übertragen.

Das ist ja genau der Punkt: C++ ist das fliegende Auto, da es beides kann...

Ich finde wiederum, Dot bringt es sehr gut auf den Punkt. Dynamische vs statische Polymorphie. Das ist genau der große Unterschied zwischen den Konzepten, wie Dot schon richtig gesagt hat. Es ist auch der Grund, unter der die Performance so leidet. Auch wenn man das wohl heutzutage auch häufig vernachlässigen kann. Die Frage die ich mir immer stelle: Ist dynamische Polymorphie wirklich notwendig?

Zitat von »BlueCobold«

Er wird aber nach außen getragen. So oder so.

In wie fern wird etwas nach außen getragen?
Nur weil im Header abgelesen werden kann, welcher Typ dahinter steckt?
Welche Bedeutung hat das in der Praxis?
Sind private Member in C++ für dich also auch nach außen getragen, weil ihre Beschaffenheit im Header abgelesen werden kann?
Wahrscheinlich ja, aber welche Auswirkungen soll das nun in der Praxis haben?
In C# gibt es die Trennung zwischen Implementierung("Source") und Schnittstelle("Header") gar nicht.

Zitat von »BlueCobold«

Dot, ohne dich angreifen zu wollen, aber etwas mehr praktischer Bezug und etwas weniger theoretische Wissenschaftlerei wäre manchmal ganz wünschenswert.

BlueCobold, ohne dich angreifen zu wollen, muss ich sagen das deine Argumentation mindestens genauso stark theoretische Wissenschaftlerei ist.
Ich kann mich erinnern, dass du geschrieben hast, dich würde es stören das Dot immer soviel philosophiert.
Die Frage danach, ob etwas "nach außen getragen wird" bzw. der Auswirkungen davon, stufe ich jedoch noch wesentlich philosophischer ein.

Zitat von »BlueCobold«

Ich finde es allerdings sehr traurig, wie Deine Wortwahl ausfällt

Welche Wortwahl gefällt dir nicht?
Dot hat sehr sachlich geantwortet, niemanden angegriffen und die Tatsachen auf den Punkt gebracht.

Ich sehe einen großen Unterschied zwischen statischer und dynamischer Polymorphie.
Beim Entwickeln von von einigen Klassen, gerade auf Sprach und nicht Spielentwicklerebene, ist das mit unter eine der ersten Fragen die man sich stellen sollte.
An konkreten Beispielen in der Praxis lässt sich Performance schlecht festmachen. Ich weiß weder wie schnell das Spiel läuft, weil ich es nicht kenne, noch weiß ich wieviel dadurch in einem konkreten Fall verloren geht. Beispielalogrithmen bei denen das deutlich zu Buche schlägt, habe ich genannt. Ob das konkret in diesem Spiel Auswirklungen hat, bezweifle ich. Es kommt nicht auf die Leistung des Gesamtsystems an oder der absolute Zeitverlust, sondern auf Anzahl Iterationen, die Anforderungen und die Aufgabenstellung. Performance ist allerdings in vielen Fällen trotzdem ein schlechtes Argument.
Auf Mikrocontroller < 10Mhz gibt es in der Regel gar keine Polymorphie.

Zitat von »Spiele Programmierer«

Ist dynamische Polymorphie wirklich notwendig?

Ja. Sonst gäbe es sie ja nicht und auch Vererbung wäre wohl kein relevantes Thema. OOP ist aber sicher nicht so groß, weil es "kool" ist. Dynamische Polymorphie ist da ganz sicher ein wichtiger Faktor.

Zitat von »Spiele Programmierer«

In wie fern wird etwas nach außen getragen?
Nur weil im Header abgelesen werden kann, welcher Typ dahinter steckt?

Weil es als public jedem mitgeteilt wird.

Zitat von »Spiele Programmierer«

Welche Bedeutung hat das in der Praxis?

Die Bedeutung ist die, dass damit Schundluder getrieben wird. Es hat nicht zu interessieren, welcher Container konkret dahinter steht.

Zitat von »Spiele Programmierer«

Sind private Member in C++ für dich also auch nach außen getragen, weil ihre Beschaffenheit im Header abgelesen werden kann?

Nein. Die sind privat.

Zitat von »Spiele Programmierer«

Beim Entwickeln von von einigen Klassen, gerade auf Sprach und nicht Spielentwicklerebene, ist das mit unter eine der ersten Fragen die man sich stellen sollte.

Natürlich. Nur sollte die Frage in Bezug dazu stehen, WAS man braucht und NICHT, ob das eine nun schneller ist als das andere, weil man dort virtuelle Calls macht oder nicht. Beide Dinge haben völlig verschiedene Anwendungsfälle.

Zitat von »Spiele Programmierer«

Es kommt nicht auf die Leistung des Gesamtsystems an oder der absolute Zeitverlust, sondern auf Anzahl Iterationen, die Anforderungen und die Aufgabenstellung.

Der Algorithmus muss optimiert werden und erst danach muss man die Frage stellen, ob sich technisch noch was drehen lässt. Nicht andersrum. Sich von Anfang an daran aufzuhängen, dass eine Lösung virtuelle Calls macht und die andere nicht, sagt noch lange nichts darüber aus, welche letztlich die geringere Laufzeitkomplexität aufweist.

Zitat von »Spiele Programmierer«

Auf Mikrocontroller < 10Mhz gibt es in der Regel gar keine Polymorphie.

Was aber nicht nur daran liegt, dass sie generell vermieden wird, sondern auch daran, dass die zu lösenden Probleme dort gar keine Polymorphie erfordern.