spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

std::vector hat doch die Methode erase

Fürs Durchiterieren bieten sich Iteratoren an. Erstens senkt man die Anforderungen an den konkreten Containertyp (hier operator[]), zweitens hat man gleich ein Argument für erase() zur Hand.

Vom Design her habe ich hier allerdings nicht gerade ein gutes Gefühl. :p
Ist das sf::RenderWindow global deklariert?

P.S.: sf::Randomizer initialisiert sich selbst.

@E122: was sehr langsam ist. warum verwendest du nicht list?
anstatt den asterioden zu löschen könntest du ihn einfach sehr weit nach oben setzen(negative y koordinate) an einer zufälligen x koordinate.
dann sieht es so aus als würde er nach ein paar sekunden neu kommen obwohl er die ganze zeit da war.
so sparst du dir das löschen.
ich würde ihn aber nur zeichnen wenn seine y koordinate über -50 ist sonst kostet das ganze wieder unnötige resourcen.

Zitat von »"NachoMan"«

was sehr langsam ist. warum verwendest du nicht list?

Naja. Bei so wenigen Asteroiden dürfte das nichts ausmachen. Zumal es ja noch die Möglichkeit gäbe, ungeordnete Elemente in O(1) aus dem std::vector zu löschen.

es geht ja nicht wirklich um die performance sondern darum, dass er sich angewöhnt sich immer die schnellste möglichkeit auszudenken. wenn die spiele nachher komplexer werden muss er das nicht erst neu lernen.

Zitat von »"Genro"«

Wie benutze ich den erase..

Schau dir vielleicht mal die Einführung in die STL an, dort werden solche grundlegende Dinge erklärt. Auf www.cplusplus.com findest du ausserdem eine Dokumentation zu den Klassen, Funktionen und Templates der Standardbibliothek.

Zitat von »"NachoMan"«

es geht ja nicht wirklich um die performance sondern darum, dass er sich angewöhnt sich immer die schnellste möglichkeit auszudenken. wenn die spiele nachher komplexer werden muss er das nicht erst neu lernen.

Das stimmt, aber du weisst ja nicht, was er sonst noch für Operationen auf den Container anwendet. Der STL-Container std::list hat zudem 8 Byte Overhead pro Element, und jedes Element muss einzeln allokiert und deallokiert werden. Da der Standard-Allokator für grössere Objekte optimiert ist, braucht der new-Operator relativ viel Zeit, ausserdem kommen nochmals einige Bytes an verstecktem Verwaltungsaufwand hinzu. Im Weiteren gibt es etliche andere Faktoren, wie Invalidierung von Zeigern, Random-Access, die eine Containerwahl beeinflussen können. Das sollte man alles auch bedenken, bevor man voreilige Schlüsse zieht.

Davon abgesehen wird Genro sowieso noch einiges zu lernen haben, wenn er sich grösseren Projekten zuwendet. Gerade im Bezug aufs Programmdesign und die Aufgabenverteilung von Klassen wäre sicher noch einiges zu machen, was momentan noch unwichtig zu sein scheint.

Zitat

was sehr langsam ist. warum verwendest du nicht list?

Hä, ich hab doch ihm ein Beispiel gemacht, und da er vector benutzt, würde ihm doch eine Lösung für List nichts helfen !

Zitat

dass er sich angewöhnt sich immer die schnellste möglichkeit auszudenken. wenn die spiele nachher komplexer werden muss er das nicht erst neu lernen.

Leutz, Leutz. Das war ein Beispiel für Genro. Ich hab jetzt nicht sonderlich geachtet, ob das Beipsiel perfomancetechnisch der Hit ist. Ein Beispiel ist schliesslich keine Performancekritische Operation in meinem Quellcode