Anforderung:
- Sehr häufiges iterieren von begin() bis end()
- Enthält Zeiger auf Klassen die kontrolliert zu bestimmen Zeiten gelöscht werden müssen
- sofortiges löschen von elementen an beliebiger stelle
- performant

Man sagt, std::list sei die inperformante Wahl der Container wenns um Spiele geht.
Welchen würden unsere Forenexperten empfehlen?

Verwendung:
In diesen Containern werden in einem Spiel gespawnte Gegner gespeichert.
Diese werden 1x pro Frame durchlaufen und die update Funktion aufgerufen, sowie Kollisionstest durchgeführt und auch wieder entfernt. Um eben ein erneutes iterieren zu sparen wird der Gegner sofort entfernt.

Beispiel:

void GameStateGame::onUpdate( const u32 delta, const u32 time )
{
	m_shoot_timer += delta;
	m_spawn_timer += delta;
	m_player_shoot_timer += delta;
	if ( m_spawn_timer >= m_spawn_rate )
	{
		int interval = GameManager::getInstance().getRandomNumber(m_shoot_rate - 200, m_shoot_rate);
		EnemyShip* e = new EnemyShip(new SimpleLaser(), interval);
		m_enemies.push_back(e);
		m_spawn_timer = 0;
	}
	TEnemyList::iterator it_e = m_enemies.begin();
	for ( it_e; it_e != m_enemies.end(); it_e++ )
	{
		EnemyShip* e = *it_e;

		if ( e->getPosition().x <= -200 )
		{
			e->sleep();
			if ( e->canBeDeleted() )
			{
				it_e = m_enemies.erase(it_e);				
				delete e;
				if ( it_e == m_enemies.end() ) break;
			}
		}
		else
		{
			e->update(delta, time);
		}
	}
	m_player->update(delta, time);
}

Das ist jetzt so eine funktion aus meiner GameStateKlasse.
Danke für eventuelle Tipps, bin mir gerade unsicher welchen Container ich nehmen soll.

p.s.: Ich weiss dass const hier nicht nötig ist für ein unsigned int. Ich mache das alleine zur Fehlervermeidung wie if ( delta = 0 ). Danke.

Könnte mit SeppJs Methode eine std::deque nicht sogar besser sein (besonders was das Löschen angeht)?

deque würde ich nicht nehmen, wenn es auf Geschwindigkeit ankommt. Für deque spricht nur, dass Einfügen und Löschen am Anfang eine bessere Komplexitätsklasse hat als beim vector. Aber sonst sind die Konstanten viel größer als bei vector, außer eventuell beim Anhängen am Ende, was ähnlich schnell geht. Aber dafür wird der Elementzugriff lahm, was oftmals nicht gewünscht wird.

Das relativiert sich natürlich, falls es die Operationen auf den Elementen sind, die die Zeit verbrauchen, aber das wird hier wohl nicht der Fall sein, sonst würde ja nicht ausdrücklich nach einem schnellen Container gefragt. Und da ist vector allen anderen Containern deutlich überlegen.

(Das ist natürlich alles nicht Standard, da der Standard nur Komplexitätsklassen vorschreibt. Die Schnelligkeit von vector ergibt sich dann aber in der Praxis aus der einfacheren Implementierung von vector, der einfach nicht so viele Anforderungen erfüllen braucht).

Die Reihenfolge wäre in dem Fall nicht wichtig.
Wie schaut deque vs vector aus was Jodocus ansprach?
Das mit nach hinten schieben wird schwierig weil pro Durchlauf auch mehrere Elemente ungültig werden können. Klar, der reihe nach aber wie gut eignet sich da swap?

Nimm das mit dem Verschieben nicht so wörtlich. Das ist eher so gemeint:

loesche element N aus liste. Dazu:
 1. liste[N]=letztes element aus liste
 2. letztes element loeschen

Also einfach Zuweisung und resize(size-1). Eine ganz ganz billige Operation. Danach geh'ste bei Element N weiter.

Wenn es um Zeiger geht sollte das natürlich egal sein. Es sei denn es wären Smart-Pointer, dann ist swap() wieder der klare Sieger.
Mit std::unique_ptr geht nur swap(), und mit std::shared_ptr wird swap() ein gutes Stück schneller sein als operator =.

Und: ganz klar vector wenn einfügen/löschen am Anfang nicht benötigt wird.

#define deque_size 16; //power of 2
T map[x][deque_size];
size_t offset;
//...
T operator*()
{
 size_type block = offset / deque_size;     //könnte vom Compiler zu nem shift optimiert werden
 size_type off = offset & (deque_size - 1); //entspricht modulo

 return map[ block ][ off ];
}

Also doch ein paar Befehle mehr als bei einem vector.

Im Endeffekt läufts auf folgendes hinaus:
Hinzufügen eines Elements wenn noch Speicher im Container frei ist:
vector: O(1)
deqeue: O(1)
Hinzufügen eines Elements in einen vollen Container:
vector: Kopieren aller Elemente in neuen Speicherbereich: O(n)
deque: Kopieren aller Map-Elemente in neuen Speicherbereich: O(m) (m = n / deque_size)
Wenn die Anzahl deiner Elemente relativ konstant ist fällt das aber nicht wirklich ins Gewicht.

Wie wärs mit dem Container?
http://de.academic.ru/dic.nsf/dewiki/1359077

Hmm, gefüllt mit Festplatten eine extrem gute Datenrate, selbst bei Lieferung ans andere Ende der Welt. Aber die Latenz lässt zu wünschen übrig und das ist bei Spielen wichtiger.

Wie wärs mit dem Container?
http://de.academic.ru/dic.nsf/dewiki/1359077

Beim dem Funktionsumfang dauert die Allokierung zu lange :p.
Danke an alle

Vereinfacht:
deque: konstant langsamere Zugriffszeit per Index - bei Verwendung von Iterator (denke ich) wenig spürbar
vector: komplettes Umkopieren, falls Speicher nicht ausreichend (kann insbesondere bei großen Vektoren zu ruckeln führen)

Aber mach dir keinen so großen Kopf drum.
Definier dir doch einfach ein typedef und probier es aus.
Wenn es nicht paßt, dann ändere den Typen.

Gruß,
XSpille

deque: konstant langsamere Zugriffszeit per Index - bei Verwendung von Iterator (denke ich) wenig spürbar

Da denkst du falsch, auch Iterator-Operationen werden langsamer.

XSpille schrieb:

deque: konstant langsamere Zugriffszeit per Index - bei Verwendung von Iterator (denke ich) wenig spürbar

Da denkst du falsch, auch Iterator-Operationen werden langsamer.

Außerdem ist bei deque imho kein O(1) Index-Zugriff garantiert.

Komplexitätstheoretisch sollte eine deque äquivalent zu einer list sein, sofern die block size konstant ist..

Und deque ist von der Komplexität her sicher nicht mit list vergleichbar, sonst wäre die Klasse wohl ziemlich sinnlos

Nachdem eine deque Random-Access Iteratoren hat, müsste der Zugriff amortisiert O(1) sein. Bloss wird er linear langsamer sein als bei vector.

Kannst Du mir die Stelle im Standard nennen? Ich habe gestern nämlich danach gesucht, aber nichts gefunden. Allerdings habe ich auch nichts zu O(1) Zugriff bei vector gefunden Dementsprechend werde ich den entsprechenden Abschnitt wohl irgendwie übersehen haben ;).

Edit: Habs gefunden: 23.1.1 Tabelle 71 in meinem Draft hier:
"Table 71 lists sequence operations that are provided for some types of sequential containers but not others. An implementation shall provide these operations for all container types shown in the “container” column, and shall implement them so as to take amortized constant time."
Demnach muss deque amortisiert O(1) für push_back , push_front und operator[] implementieren.

Also schon anders als eine list . Da hatte ich was falsches im Kopf ;).

Und was genau meinen die mit intrusive?

Auch werden dabei die Elemente direkt eingefügt und keine Kopien gemacht.

http://www.boost.org/doc/libs/1_36_0/doc/html/intrusive/intrusive_vs_nontrusive.html#intrusive.intrusive_vs_nontrusive.differences_intrusive_vs_nontrusive

BTW: willst du Zeiger auf die Objekte in die intrusive list stecken, oder dann die Objekte selbst? Die ganzen intrusive Container funktionieren ja auch mit abgeleiteten Klassen.

Wenn du die Objekte selbst in die intrusive list stecken kannst, dann bringt das vermutlich ein bisschen was.

Die doppelt verkettete intrusive List ist auch nicht viel langsamer.

BTW: willst du Zeiger auf die Objekte in die intrusive list stecken, oder dann die Objekte selbst? Die ganzen intrusive Container funktionieren ja auch mit abgeleiteten Klassen.

Wenn du die Objekte selbst in die intrusive list stecken kannst, dann bringt das vermutlich ein bisschen was.

Hmm, naja ich erzeuge meine Objekte auf dem Heap. Hat den Grund, dass ich genau definieren muss wann diese zerstört werden damit keine Memory Leaks entstehen. Sprich, bevor der OpenGL Context zerstört wird.
Im prinzip steke ich da ja nur nen Zeiger darauf "rein". Aber bei "C"-Style verketteten Listen biegt man ja auch nur Zeiger hin und her.
Das Problem bei STL-Containern ist halt, dass diese nochmal kopieren.
Ich geb zu, ich habe so meine Probleme mit Containern...

Dann musst du aber wirklich die Objekte selbst in die intrusive List stecken, und nicht eine Hilfsklasse mit nur einem Zeiger.