Problem mit tr1::unordered_map

[HaJo.]

MFK schrieb:

tr1::unordered_map garantiert keine bestimmte Reihenfolge der Elemente.

Hmm, das ist gut zu wissen. Das heißt für einen Vergleich müsste ich durch eine Map iterieren, in der anderen Map mit find nach Schlüssel und Wert suchen und diese dann vergleichen.

Garantiert die std::map eine Reihenfolge? Oder welcher Schlüssel/Wert Datentyp wäre für einfache Liste, die nach "Einfügen der Elemente" "sortiert" ist?

[Tachyon]

HaJo. schrieb:

MFK schrieb:

tr1::unordered_map garantiert keine bestimmte Reihenfolge der Elemente.

Hmm, das ist gut zu wissen. Das heißt für einen Vergleich müsste ich durch eine Map iterieren, in der anderen Map mit find nach Schlüssel und Wert suchen und diese dann vergleichen.

Garantiert die std::map eine Reihenfolge? Oder welcher Schlüssel/Wert Datentyp wäre für einfache Liste, die nach "Einfügen der Elemente" "sortiert" ist?

Für eine sortierte Collection solltest Du eine std::map nehmen, ja. Die Schlüssel-Wert-Paare werden beim Einfügen sortiert. Das Sortierkriterium lässt sich ggf. selbst festlegen.
Eine std::tr1:: unordered _map is, wie der Name bereits sagt, unsortiert.

[LordJaxom]

Map garatiert eine Reihenfolge, die durch die Vergleichsfunktion der Map bestimmt wird, welche standardmäßig der operator< des Keys ist.

[HaJo.]

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.

[Bulli]

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?

[Tachyon]

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.

[HaJo.]

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.

[volkard]

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.

[Shade Of Mine]

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...

[HaJo.]

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.

[Tachyon]

volkard schrieb:

Es kommt drauf an, was Du machen willst. Bei langen strings sind ordered maps zum suchen wieder besser.

Wieso das denn?

[volkard]

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.

[Tachyon]

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?

[volkard]

Tachyon schrieb:

Und wieso sollten die Stringvergleiche früh abbrechen?

weil sie beim ersten unterschied abbrechen.