spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Oder man nimmt eine Map und std::string. Ist *vielleicht* ja doch am Ende die sinnvollere Lösung, sowohl von der Laufzeit, als auch vom Aufwand es umzusetzen - schön sind ja z.B. auch Hash-Kollisionen, die komplett ignoriert wurden.

BlueCobold ist einfach der Beste und danke für den Fisch.

Na mal ernsthaft, wieso nutzt man statt einer O(log N) Datenstruktur lieber eine O(n) Datenstruktur, die für eine Hash-Berechnung länger braucht als ein String Compare und die auch noch Hash-Kollisionen nicht behandelt? Das macht std::map *alles* definitiv besser und optimaler. Wenn das kein Trolling-Versuch war, dann weiß ich auch nicht. Daher auch der Fisch.

Wenn man mit Hashes arbeiten will könnte man ja auch die unordered_map probieren. Wenn man an der Stelle wirklich ein Problem hat.

unordered_map wäre ein Kompromiss bei dem fast alle Nachteile von beiden Möglichkeiten erhielten blieben.
Wenn man jemals fertig werden will sollte man in diesem Fall die sortierte Map mit std::string als key nehmen.
Wenn man damit leben kann immer an einem Prototypen oder an sehr kleinen Projekten zu arbeiten kann man sich hier auch nen sortierten std::vector mit Hashkey basteln.

Natürlich.

nur weil jemand am markansten seine Meinung vertritt, hast er immer recht?

Hast Du mal google nach std::map gefragt? Warum gibt es so viele Artikel die von der Verwendung
von std::map abraten? Weil sie langsam ist. Weil die Einträge eventuell wild im Speicher verteilt sind.
Ich verwende extra in Array damit die Daten effizient aus dem Speicher geladen werden können.
Sie liegen alle sequentiell dort. Bei einer Map auch?

Warum gibt es so viele Leute die sagen, dass std::string in einer Game Engine außer für Textmessages
und Debugging nichts verloren haben? Sind das alles so Trolle wie ich, die sich mit diesem bescheuerten
data oriented und cache friendly Zeug auseinandersetzen?

Nimm es als Denkanstoß und wenn es Dich interessiert, dann setze dich mal mit dem Thema auseinander.
Vielleicht bist Du ja etwas offener in deiner Denkweise.

Ich würde hier vermutlich std::unordered_map verwenden. In der Praxis wird es aber kaum einen Unterschied machen, da wir es wohl mit maximal in der Gegend von hundert Ressourcen zu tun haben. Dann ist es sogar sehr wahrscheinlich, dass simple lineare Suche in einem std::vector die beste oder zumindest relativ gute Performance liefern würde. In Anbetracht der Tatsache, dass diese Funktion potentiell eine Bilddatei von der Festplatte laden geht, ist all das aber sowieso völlig irrelevant...

Zitat von »Nimelrian«

Sooo, der Compiler schmeißt keine Fehler, ich lasse euch natürlich trotzdem noch drüberschauen, bzw. poste hier den aktuellen (fertigen?) Code für alle, die eventuell mal selbst einen RM implementieren wollen

C-/C++-Quelltext

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

const sf::Texture& ResourceManager::getTexture(const std::string& filename) { auto texIt = resourceMap.find(filename); // No texture with the given filename was found, load it and move the pointer into the map if (texIt == resourceMap.end()) { std::unique_ptr<sf::Texture> tex(new sf::Texture); if (!(tex->loadFromFile(resourcePath + filename))) { throw ("The file \"" + filename + "\" can not be found at " + resourcePath + "!"); } resourceMap.insert(std::make_pair(filename, std::move(tex))); return *tex; } // Texture is in the map already, return it else { return *(texIt->second.get()); } }

In Zeile 11 dereferenzierst du hier dein tex nachdem du aus ihm gemoved hast. Das ist keine gute Idee. Wenn du aus einem std::unique_ptr movest, wird der originale unique_ptr zu nullptr...

Oh und anstatt die Map effektiv zweimal zu traversieren (einmal beim initialen find() und einmal beim insert() falls nichts gefunden wurde), könnte man einfach per [] Operator in der Map nachschauen und sich zunutze machen, dass der [] Operator im Falle, dass nichts gefunden wird, ein default-konstruiertes Objekt einfügt und dieses returned...

Zitat von »buggypixels«

nur weil jemand am markansten seine Meinung vertritt, hast er immer recht?

Hast Du mal google nach std::map gefragt? Warum gibt es so viele Artikel die von der Verwendung
von std::map abraten? Weil sie langsam ist. Weil die Einträge eventuell wild im Speicher verteilt sind.
Ich verwende extra in Array damit die Daten effizient aus dem Speicher geladen werden können.
Sie liegen alle sequentiell dort. Bei einer Map auch?

1) Die Einträge sind auf dem Heap dynamisch erzeugte Einträge, was schon allein dafür sorgt, dass sie ohnehin "wild im Speicher verteilt" sind.
2) O(log n) ist besser als O(n)
3) Ist das premature optimisation - Wenn irgendwann mal die Map sein Bottleneck sein sollte, kann er das noch umstellen. Ist allerdings anzuzweifeln, dass das jemals eintritt. Bis dahin gilt clean code und: Premature optimization is the root of all evil.
4) Data Oriented schön und gut, das ist Dein Ansatz nur leider nicht wirklich. Zudem ist das ein Paradigmen Krieg, den wohl keine Seite gewinnen wird.
5) Wie dot schon sagte hängt da ein eventuelles Laden einer Datei dran. Daran sieht man schon, WANN diese Methode überhaupt aufgerufen werden darf/sollte. Nämlich dann, wenn es sowieso nicht relevant für einen Echtzeiteinsatz ist.