Im Moment benutze ich unordered_map - aber hier ist keinerlei Reihenfolge garantiert, oder?

also soweit ich weiß heißt unordered in dem fall, dass die elemente nicht geordnet werden, also in der reihenfolge des einfügens bleiben.
ohne mehr informationen kann ich jetzt nicht sagen ob du in deinm fall besser std::vector nehmen solltest

EDIT: ups, da war jemand schneller

Ich brauche eine map mit strings als Schluessel und Zeiger als Werte, die der Reihenfolge des Einfuegens geordnet sind

WTF, das ist genau das Gegenteil von einer Map. Was soll passieren, wenn du zwei mal den gleichen Schlüssel einfügst? Soll der dann zwei mal vor kommen? Oder soll der alte Wert überschrieben werden?

Internally, the elements in the unordered_map are not sorted in any particular order with respect to either their key or mapped values, but organized into buckets depending on their hash values to allow for fast access to individual elements directly by their key values (with a constant average time complexity on average).

Zum Thema Hashing kannst du ja mal bei wikipedia lesen:
http://de.wikipedia.org/wiki/Hashing
oder es sollte genug andere Quellen im Netz geben.

Gruß
XSpille

Bei Bedarf kann ich den Source zuhause mal raussuchen

Nee, erklaer erstmal das Problem. Warum Zweitcontainer? Was willst du machen, nicht wie!

Die pair/find Loesung ist zu langsam, da O(n).

@Th69
Das hatte ich auch vor, aber ich hatte doch noch gehofft, dass es eine schoenere Loesung gibt. Naja, dann eben nicht ..

Das hast du aber wieder bei einer normalen std::map, dort müsste die Zugriffszeit bei O(log n) liegen (weil Baum).

Auch genannt wurde ein queue, bzw in dem Fall der priority_queue (ist das Wort queue jetzt eigentlich männlich, weiblich oder beides?!? ich sag nur "Der Kalkül")

Aber du willst Speed, vergleichst aber dann Strings? Widerspricht sich in meinen Augen...

Auch genannt wurde ein queue, bzw in dem Fall der priority_queue (ist das Wort queue jetzt eigentlich männlich, weiblich oder beides?!? ich sag nur "Der Kalkül")

"Die" Warteschlange.

"Die" Warteschlange.

Das std::set = das Menge?

Ansonsten geht die direkte Übersetzung von Datenstrukturen aber ziemlich oft mit den Artikeln auf:

• der Vector (Vektor)
• die List (Liste)
• die Deque (doppel-endige Warteschlange)
• die Map (Karte/Abbildung)
• das Array (Feld)
• der Stack (Stapel)
• die Queue (Warteschlange)
• der Tree (Baum)
• der Heap (Haufen)

Bei "Set" könnte das Neutrum daher rühren, dass es bereits deutsche Nomen wie das "Filmset" gibt. Gleiches gilt wohl für den "String"

Und wie Skym0sh0 bereits geschrieben hat: Stringvergleich (und u.U. das Bilden von Hashes) sind nicht unbedingt die schnellsten Vorgehensweisen beim Adressieren von Elementen in einem Container.

Die map Schluessel (als String) sind die Bezeichner der Objekte und werden vom Benutzer selbst festgelegt. Je nach Eingaben des Benutzers muss ich dann per Bezeichner auf die Objekte zugreifen koennen.

Also: eine her geringe Anzahl von Objekten und der Zugriff über die map wird signifikant seltener eintreten als das Zeichnen?

=> vector<pair<string,Objekt> > mit push_back für neue Elemente. nach namn gesucht wird mit find_if oder ähnlichem.

Gib deinen Objekten eine z Koordinate mit und ordne sie in deiner map nach eben diesen Koordinaten.

Naja, Stringvergleiche sollten in O(n) zu schaffen sein (wobei n die Länge des Strings) und Hashes sollten in O(1) machbar sein (O(n) wäre hier nur nutzbar, wenn n die Größe des Datentyps ist).

Wobei das auch wieder nur theoretische Betrachtungen sind.
Zb der GCC verwendet builtin strcmp, was sauschnell ist, wenn ein String eine Compilezeitkonstante ist.

In einer Hashmap muss zuerst der KOMPLETTE String gehasht werden, und dann muss nochmal mindestens 1 Knoten an einer linked List gehangelt werden, was nach Cache-misses schreit.

Wenn die Map sehr stark unterschiedliche Strings enthält wie

map<string, int> alter;
alter["Albert"] = 25;
alter["Berta"] = 35;
alter["Christoph"] = 45;
...

int alterVonMarianne = alter["Marianne"];

kann eine naive implementierung über einen Vector relativ lange effizient genug sein.

Skym0sh0 schrieb:

Gib deinen Objekten eine z Koordinate mit und ordne sie in deiner map nach eben diesen Koordinaten.

So hab ichs jetzt gemacht, da so ne z Koordinate sowieso noch eine gute Idee war

Aber wie kann ich sowas am bestem implementieren? map/multimap kann ja nur nach key sortieren...

Ich habs jetzt so gemacht, dass ich mir ne Klasse geschrieben habe welche eine std::multimap abstrahiert die die z Koordinaten als Key verwenden und ein pair aus string und zeiger als mapped_type. Key-Zugriff ist zwar nicht mehr direkt moeglich (sondern es muss nach mit find_if gesucht werden), aber notfalls kann ich noch einen zusaetzlichen unordered_map container verwenden, falls es zu langsam wird... Aber im Moment klappts ganz gut so.

Die map Schluessel (als String) sind die Bezeichner der Objekte und werden vom Benutzer selbst festgelegt. Je nach Eingaben des Benutzers muss ich dann per Bezeichner auf die Objekte zugreifen koennen.

Ich würde mit einer separaten unordered_map arbeiten, die strings auf Objekte abbildet. Insbesondere, da es wohl wesentlich wichtiger ist, schnell über die Objekte iterieren zu können. Der User wird kaum merken, ob der Lookup eines Objektes über seinen Namen jetzt 10 Mikrosekunden oder 100 Mikrosekunden dauert...

Eric Cartman schrieb:

Die pair/find Loesung ist zu langsam, da O(n).

Wieviele zehntausend Objekte sind es denn, dass das zu langsam ist?