Ich habe ein merkwürdiges Problem mit der std::tr1::unordered_map. Und zwar habe eine Klasse geschrieben, die als privaten Member eine solche Map enthält. Zudem hat die Klasse die Operatoren "==" und "=" überladen. In einem Testdurchlauf mit weniger Elementen als 66 (<= 66) ist alles ok. Wenn ich 66 oder mehr Elemente hinzufügen und vergleiche sind die Maps plötzlich nicht mehr gleich. Ich verstehe leider nicht ganz warum.

Hier einmal der Code:

#include <iostream>
#include <unordered_map>

// Map Klasse
class MyMap
{
private:

    typedef std::tr1::unordered_map<int, int> mm;

    std::tr1::unordered_map<int, int> m_Map;

public:

    bool Add(const int & Key, const int & Value)
    {
        return this->m_Map.insert(mm::value_type(Key, Value)).second;
    }

    const bool operator == (const MyMap & rhs) const
    {
        if (this != &rhs)
        {
            if (this->m_Map.size() != rhs.m_Map.size())
                return false;

            for(mm::const_iterator it_lhs = this->m_Map.begin(), it_rhs = rhs.m_Map.begin();
                    it_lhs != this->m_Map.end() && it_rhs != rhs.m_Map.end();
                    it_lhs++, it_rhs++)
            {
                if (it_lhs->first != it_rhs->first || it_lhs->second != it_rhs->second)
                    return false;                
            }
        }

        return true;
    }

    const MyMap & operator = (const MyMap & rhs)
    {
        this->m_Map.clear();

        if (rhs.m_Map.empty())
            return *this;
        else
        {
            for(mm::const_reverse_iterator it_rhs = rhs.m_Map.rbegin(); it_rhs != rhs.m_Map.rend(); it_rhs++)
            {
                this->Add(it_rhs->first, it_rhs->second);
            }
        }

        return *this;
    }
};

int main(int argc, char ** argv)
{
    MyMap m1, m2;

    for (int i = 0; i < 66; i++) // <= 66 ist alles ok, mit >= 66 sind die Maps nicht mehr gleich
    {
        m1.Add(i, i);
    }

    m2 = m1;

    std::cout << "Vergleich: " << (m2 == m1) << std::endl;
	return 0;
}

Wenn ich 66 oder mehr Elemente hinzufügen und vergleiche sind die Maps plötzlich nicht mehr gleich. Ich verstehe leider nicht ganz warum.

tr1::unordered_map garantiert keine bestimmte Reihenfolge der Elemente.

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?

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.

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.

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?

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.

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.

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.

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

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.

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

Wieso das denn?

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

Und wieso sollten die Stringvergleiche früh abbrechen?

weil sie beim ersten unterschied abbrechen.