Problem mit tr1::unordered_map
-
LordJaxom schrieb:
Map garatiert eine Reihenfolge, die durch die Vergleichsfunktion der Map bestimmt wird, welche standardmäßig der operator< des Keys ist.
Super danke. Also bei ganzzahligen Werten, die monoton steigen/fallen ist eine map die Wahl.
Bei Strings wäre dann z.B. ein std::vector mit einem Objekt<Key, Value> die Wahl, wenn die Werte nicht geordnet werden sollen.
-
HaJo. schrieb:
LordJaxom schrieb:
Map garatiert eine Reihenfolge, die durch die Vergleichsfunktion der Map bestimmt wird, welche standardmäßig der operator< des Keys ist.
Super danke. Also bei ganzzahligen Werten, die monoton steigen/fallen ist eine map die Wahl.
Bei Strings wäre dann z.B. ein std::vector mit einem Objekt<Key, Value> die Wahl, wenn die Werte nicht geordnet werden sollen.
Wie das denn? Du kannst der Map eine Vergleichfunktion für Strings übergeben. Warum sollte man keine Strings in einem Map nutzen sollen?
-
HaJo. schrieb:
Bei Strings wäre dann z.B. ein std::vector mit einem Objekt<Key, Value> die Wahl, wenn die Werte nicht geordnet werden sollen.
Es kommt drauf an, was Du machen willst. Wenn es Dir um schnelles Suchen geht, wären die unordered_* Container besser.
-
Bulli schrieb:
Wie das denn? Du kannst der Map eine Vergleichfunktion für Strings übergeben. Warum sollte man keine Strings in einem Map nutzen sollen?Sorry. Ich habe mich wohl etwas missverständlich ausgedrückt. Natürlich lassen sich Strings in u-/maps nutzen.
Ich wollte nur einen Container, der Wert/Schlüssel nicht nach Schlüssel sortiert, sondern der Reihe nach einfügt.
Falls die Schlüssel Zeitstempel beispielsweise sind, ist ein map möglich da die Zeitstempel monoton steigend vorkommen.
Falls die Schlüssel vom Datentyp String sind, und diese nicht mit < oder > der Größe nach geordnet werden sollen, ist weder map noch u-map eine Wahl.
-
Tachyon schrieb:
HaJo. schrieb:
Bei Strings wäre dann z.B. ein std::vector mit einem Objekt<Key, Value> die Wahl, wenn die Werte nicht geordnet werden sollen.
Es kommt drauf an, was Du machen willst. Wenn es Dir um schnelles Suchen geht, wären die unordered_* Container besser.
Es kommt drauf an, was Du machen willst. Bei langen strings sind ordered maps zum suchen wieder besser.
-
HaJo. schrieb:
Ich wollte nur einen Container, der Wert/Schlüssel nicht nach Schlüssel sortiert, sondern der Reihe nach einfügt.
Dann willst du ein vector<pair<Key, Value> > haben... und keine map...
-
volkard schrieb:
Es kommt drauf an, was Du machen willst. Bei langen strings sind ordered maps zum suchen wieder besser.
Ahh. Gut zu wissen. Danke.
Shade Of Mine schrieb:
Dann willst du ein vector<pair<Key, Value> > haben... und keine map...
Oder so. Ist warscheinlich besser, wg. Verwendung der STL.
-
volkard schrieb:
Es kommt drauf an, was Du machen willst. Bei langen strings sind ordered maps zum suchen wieder besser.
Wieso das denn?
-
Tachyon schrieb:
volkard schrieb:
Es kommt drauf an, was Du machen willst. Bei langen strings sind ordered maps zum suchen wieder besser.
Wieso das denn?
weil das berechnen des hashcodes passiert, indem der ganze lange string gelesen wird. das kann teurer sein, als zehn strungvergleiche, die früh abbrechen.
-
volkard schrieb:
Tachyon schrieb:
volkard schrieb:
Es kommt drauf an, was Du machen willst. Bei langen strings sind ordered maps zum suchen wieder besser.
Wieso das denn?
weil das berechnen des hashcodes passiert, indem der ganze lange string gelesen wird. das kann teurer sein, als zehn strungvergleiche, die früh abbrechen.
Und wieso sollten die Stringvergleiche früh abbrechen?
-
Tachyon schrieb:
Und wieso sollten die Stringvergleiche früh abbrechen?
weil sie beim ersten unterschied abbrechen.