spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich finde ja eher, das wäre ein Fall für std::vector. Der macht nämlich genau das, nur noch mit ein paar Fehlerchecks.

Entweder war Dots Post ein Scherz oder es geht ihm darum, dass niemand die größe Nachträglich ändern kann. Quasi ein Vector ohne Resize, Erase, Pop und Push.

Zitat von »NachoMan«

[...] oder es geht ihm darum, dass niemand die größe Nachträglich ändern kann. Quasi ein Vector ohne Resize, Erase, Pop und Push.

Bingo

Zitat von »drakon«

Ein std::vector hat einen minimalen Mehraufwand bei dem Zugriff auf ein Element.

Moment, wieso? Klar, im Debugbuild sind alle Range-Checks drin, aber im Releasemode sollte der Elementzugriff über den [] genauso schnell wie bei jedem Array sein. Die Mehrkosten sind eher auf der Speicherseite, wo neben ein paar Zusatzinfos insbesondere noch Speicher für zukünftige Elemente schonmal reserviert ist.

Der vector bedeutet eine zusätzliche Indirektion.

Zitat von »Jonathan_Klein«

Zitat von »drakon«

Ein std::vector hat einen minimalen Mehraufwand bei dem Zugriff auf ein Element.

Moment, wieso? Klar, im Debugbuild sind alle Range-Checks drin, aber im Releasemode sollte der Elementzugriff über den [] genauso schnell wie bei jedem Array sein. Die Mehrkosten sind eher auf der Speicherseite, wo neben ein paar Zusatzinfos insbesondere noch Speicher für zukünftige Elemente schonmal reserviert ist.

Bei statischen Arrays weiss der Compiler bereits wo der Speicher ist (das offset muss natürlich noch berechnet werden) und daher muss nicht zuerst noch die Adresse geladen werden.
Pseudo Assembler (irgendwelche misch-masch Syntax ):
Statischer Zugriff:


Dynamischer Zugriff:

Im ersten Beispiel kann die Adresse direkt berechnet werden. Das offset kann auch direkt beim lade Befehl mitgebeben werden (üblicherweise).
Im zweiten Beispiel muss zuerst die Adresse des Zeigers aus der Variable, auf welche mit ecx zugegriffen werden kann (in dem Beispiel). Diese Adresse ist dann das eigentliche Ziel und wird benutzt um den eigentlichen Wert in eax zu laden.

Das teure hier ist das laden vom Speicher, welcher auf RAM zugreifen muss. Die Berechnung der Offsets ist praktisch gratis (irgendwo bei 1-4 Cycles, während der Speicherzugriff IIRC ein paar hundert kosten kann).

Ok, das macht Sinn. Ist dann aber bei dynamischen Arrays das selbe, oder nicht?

Davon habe ich ja geredet.. Zur Laufzeit verhalten sich dynamische Arrays gleich wie std::vector und statische Arrays wie std::array. Die STL Klassen sind im Grunde ja nichts anderes als Wrapper um statische, respektive dynamische Arrays.

Von std::unique_ptr für dynamische Arrays muss ich abraten: Das ist undefined behavior, da unique_ptr delete zum Löschen benutzt, für ein dynamisches Array aber delete[] benutzt werden muss. Als ersatz kann man boost::scoped_array oder eben gleich std::vector nehmen.

Zitat von »Oberon«

Von std::unique_ptr für dynamische Arrays muss ich abraten: Das ist undefined behavior, da unique_ptr delete zum Löschen benutzt, für ein dynamisches Array aber delete[] benutzt werden muss. Als ersatz kann man boost::scoped_array oder eben gleich std::vector nehmen.

Nein. std::unique_ptr ist durchaus in der Lage zwischen dynamischen Arrays und einfachen Objekten zu unterscheiden. Habe gerade keine Zeit das mit Referenz auf den Standard zu referenzieren, aber das steht auch in den gängigen Online Referenzen.
http://en.cppreference.com/w/cpp/memory/unique_ptr