spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Speicheroverhead? Im Ernst? Das sollte nun echt der letzte Grund sein sich für einen Raw Array zu entscheiden.

Ein weiterer Vorteil von normalen Arrays (+ Längenangabe) ist, dass man ohne Probleme Subarrays übergeben kann. Und man kann auch statisch gespeicherte Daten übergeben.

Zitat von »Helmut«

Ein weiterer Vorteil von normalen Arrays (+ Längenangabe) ist, dass man ohne Probleme Subarrays übergeben kann. Und man kann auch statisch gespeicherte Daten übergeben.

Naja, dafür gibt es doch iteratoren. Da bin ich sogar flexibel in welche Richtung iteriert wird und es ist egal, welchen Container ich nutze. Davon bekommt die aufzurufende Funktion einfach überhaupt nichts mit.
Sehe keinen wirklichen Grund, rohe Arrays zu nutzen.

Naja, dann musst du aus deiner ganzen Funktion ja ein template machen.

So komfortabel wie C# ist C++ nicht wenn der Code mit verschiedenen Datenstrukturen verwendbar sein soll. Dafür kann man bei C# leichter ausversehen ineffiziente Konstruktionen produzieren, besonders wenn LINQ im Spiel ist. Aus der Funktion ein Template zu machen und Iteratoren anzunehmen scheint mir da noch die beste Option zu sein. Auch wenn das evtl. nicht immer passt, wie schon von BC geschrieben.

Ist halt wie immer von Fall zu Fall unterschiedlich. Mal macht das eine Sinn, mal das andere.

@Legend
Wie schon mehrmals erläutert scheinen mir in den meisten Fällen die Möglichkeit ausgefallene Container zu übergeben total überflüssig.
Das Problem ist meistens doch eher akademisch und wer nicht gerade an einer Library wie Boost arbeitet, braucht nicht aus allem ein Template machen und seine Compilezeiten explodieren zu lassen.

In C# ist die Iteration halt sehr eingeschränkt. Da gibt es keinen bidirektionalen Iterator und alles ist virtuell. Das passt nicht in die Welt von C++ mit Zero Overhead. Du kannst auch in C++ Klassen schreiben die über virtuelle Funktionen iterieren. Der Overhead ist bloß im Vergleich so groß, das macht keiner. Und letzendlich bloß um eine std::list verwenden zu können die mit hoher Wahrscheinlichkeit in dem Fall sowieso ineffizient wäre. Man könnte natürlich eine Klasse schreiben um den Zeiger + Länge(bzw. Endzeiger) schön zu kapseln und BlueCobolds Kritik zum Komfort zu beheben. Das wäre eigentlich eine gute Idee.

Vielleicht bin ich ja echt aus der Steinzeit, aber gibt es noch Leute die so etwas machen?


Das ist ein Fall wo man ja ständig immer irgendwo etwas löscht, weil Particle ihr Lebensende erreichen.

Ja klar gibt es die.
Wieso sollte Löschen ein Problem sein?
Das ist ein typisches Beispiel für einen Container bei dem die Reihenfolge der Objekte egal ist. Somit kann man effizient aus dem std::vector löschen, in dem man das letzte Element zum eigentlich zu löschenden Element schiebt und dann das letzte Element löscht. Eine std::list wäre grauendvoll ineffizient, weil häufig über die Partikel iteriert werden muss.

Während ein eigener Container durchaus Vorteile gegebenüber dem std::vector bringen kann, so ist er hier nicht das Hauptproblem. Sinnvoll wäre die Verwendung von Datenorientierung und die ist theoretisch auch kompatibel mit dem std::vector.

Zitat von »Spiele Programmierer«

Man könnte natürlich eine Klasse schreiben um den Zeiger + Länge(bzw. Endzeiger) schön zu kapseln und BlueCobolds Kritik zum Komfort zu beheben. Das wäre eigentlich eine gute Idee.

Die Idee hatte sogar schon mal jemand. Nennt sich std::vector.