Mapping eines (Integer-)Tupels auf Vektor
-
Hallo allerseits,
ich benötige ein Konstrukt, in welchem ein Tupel von unsigned ints auf einen weiteren Datentypen (vnl_vector) gemappt wird.
Ein Beispiel eines solchen Mappings wäre folgendes:
<1,2> --> vector(4,5,6)
<2,3> --> vector(9,3,4)
<3,4> --> vector(3,4,4)
<10,20> --> vector(1,1,1)Ich hatte mir jetzt folgendes vorgestellt, um dies zu realisieren:
/// \brief A tuple of unsigned ints. typedef std::tr1::tuple<unsigned int,unsigned int> t_uint_tuple; /// \brief The set itself. std::map<t_uint_tuple,vnl_vector<double> > m_set;Hierzu habe ich zwei Fragen:
1. In den Standardbeispielen, die ich gelesen habe, wird als Key ein Standardtyp (int, char, ...) verwendet. Meine Vermutung hier ist, dass das daran liegt, dass ein Vergleich (==, !=, ...) zwischen diesen Typen leicht möglich ist. Muss ich, wenn ich ein std::tr1::tuple verwendet, neue Vergleichsfunktionen schreiben und wenn ja, wie mache ich das?
2. Hat jemand eine Idee für eine elegantere Möglichkeit, mein Problem zu lösen?
Ich hoffe, ich habe mein Problem deutlich gemacht, wenn nicht, einfach fragen und ich versuche es noch klarer zu machen.

Vielen Dank schonmal für die Hilfe,
mbu
-
Antworte ich nochmal auf meinen eigenen Post. Nach etwas Recherche, habe ich herausgefunden, dass es ja sowas wie std::pair gibt. Damit scheint es zu funktionieren, ohne irgendwelche Vergleichsoperatoren zu definieren.
std::map<std::pair<unsigned int,unsigned int>,vnl_vector<double> > m_set; /* ... */ // Hinzufügen zum Beispiel über: vnl_vector v1(8,0.0); m_set.insert( std::make_pair( std::make_pair(1,2), v1 ) );Wenn noch bessere Vorschläge existieren, bin ich aber nach wie vor offenen Ohres.
-
die Vergleichsoperatoren für tuple sind afaik schon von Haus aus überladen
-
die Vergleichsoperatoren für tuple sind afaik schon von Haus aus überladen, wenn du was eigenes brauchst, dann kannst du dem deine eigene Comparer als Templateparameter übergeen
-
Laut dem Draft ( N2798 ). Sind die Operatoren (wäre auch sehr merkwürdig wenn nicht) natürlich überladen. Das sollte nicht das Problem sein. (Auch wenn du besser die Implementierung des Compilers anschauen solltest.)