ich habe jetzt häufiger Mal std::pair genutzt, wenn ich z.B. einen vector mit exakt zwei Elementen haben wollte.

Aber nachdem diese vector-Instanzen dann großartig verwendet wurden und sich ein komplexeres Gestrüpp aufgetan hat, hab ich gemerkt, dass ich pair gar nicht so schön finde. Denn man verweist dann ständig mit first und second auf die Elemente und das sind nicht so wirklich bezeichnende Namen. Daher finde ich es eigentlich viel schöner bei zwei Elementen trotzdem eine einfache Struktur anzulegen und in den vector zu stecken, um die Lesbarkeit zu verbessern.

Pair hat natürlich schon ein paar Operatoren überladen, das ist vorteilhaft.

Wann nutzt ihr pair?

Ansonsten auch mal als Tupelmissbrauch, wobei ich da die gleichen Bedenken habe wie du. Aber bei kleinen Testprogrammen ist das egal.

Und wie Du definierst Du Paar dann, knivil? Oder meinst Du, wenn die STD-bib. ein pair verlangt?

Tupelmissbrauch

Was ist das? Ein Paar ist für mich ein 2-Tupel

std::pair benutze ich, wenn ich ein Paar brauche und der Nachteil der Namen first und second gegenüber sprechenderen Komponentennamen nicht wesentlich ins Gewicht fällt.

SeppJ schrieb:

Tupelmissbrauch

Was ist das? Ein Paar ist für mich ein 2-Tupel

std::pair benutze ich, wenn ich ein Paar brauche und der Nachteil der Namen first und second gegenüber sprechenderen Komponentennamen nicht wesentlich ins Gewicht fällt.

Tupelmissbrauch ist das was du beschreibst. Aber schlechter Name, das stimmt. Sagen wir so: Dort wo ich Objekte aus zwei Teilen habe, die nicht wirklich gut durch first und second beschrieben werden, aber wo Bequemlichkeit einem bis auf den letzten Bezeichner korrektem Design vorgezogen wird.

denn wenn ich in einem vector zwei Elemente nebeneinander habe, dann bilden diese für mich logisch auch ein Paar. Du sagst aber, dafür würdest Du pair nie nutzen. Nach meiner Aufassung von Paar widerspricht sich das einfach.

idR hat man dann eine eigene pair-Klasse. Damit man sprechende Namen hat. first und second sind immer schlechte Namen. In manchen Situationen sind sie vertretbar, aber in keiner Situation sind es gute Namen.

Weiters ist es praktisch eigene vergleichsoperatoren definieren zu können. std::pair verwendet man deshalb eigentlich nie.

Auch ist ein pair<string, string> so nichtssagend. Ein zB KeyValuePair<string, string> ist da viel schöner. Dann habe ich vielleicht noch p.key und p.value und schon macht der ganze Code mehr Sinn

idR hat manhab ich dann eine eigene pair-Klasse.[...]std::pair verwendet manverwende ich deshalb eigentlich nie.

FTFY

Der Nachteil einer eigenen pair-Klasse ist, dass das eine weitere Klassendefinition ist, die man erstmal nachschlagen und lesen und verstehen muss. Bei einem std::pair weiß jeder sofort Bescheid.

Auch ist ein pair<string, string> so nichtssagend. Ein zB KeyValuePair<string, string> ist da viel schöner. Dann habe ich vielleicht noch p.key und p.value und schon macht der ganze Code mehr Sinn

Wo warst du als std::map entworfen wurde?

dann bilden diese für mich logisch auch ein Paar

Klar ist das ein Paar, deshalb wuerde ich std::pair benutzen und nicht std::vector .

Du sagst aber, dafür würdest Du pair nie nutzen.

Nein, ich wuerde std::pair nicht als Ersatz fuer einen Vektor mit zwei Elementen benutzen, ich wuerde std::vector mit zwei Elementen auch nie als Ersatz fuer ein std::pair verwenden. Es wird einen Grund fernab von "Paar" geben, warum std::vector benutzt wird oder nicht.

Und wenn alles nichts hilft: std::vector benutzt intern new . Die Frage ist also: Will man bei zwei Elementen dynamische Speicherallokation?

Quintessenz: Benutze sie wann du willst! Punkt.

Gott man kann seine Zeit auch anders verplempern.

Gott man kann seine Zeit auch anders verplempern.

Du soltlest deine Beispiel mal statt mit bechern und Waffeln mit Giftbehältenr machen. "Ist da nun Gift drin, oder Eis?" - "Egal, ist beides Braun".

Ein std::pair ist absolut nichts sagend. Du kannst natürlich alles mit std::pair voll kleistern, aber dann musst du damit leben, dass jeder in Zukunft bei jeder Benutzung nachschlagen muss, was nun in first oder second drin ist.

Oh auf einmal verplemperst du also die Zeit andere Leute mit std::pair? Hättest du auch in dieser Diskussion tun können.

Weiters ist es praktisch eigene vergleichsoperatoren definieren zu können. std::pair verwendet man deshalb eigentlich nie.

Ich verwende std::pair ab und zu gerade wegen der Ordnung, nämlich um keinen Boilerplate-Code für Strict Weak Ordering mit zwei Elementen zu schreiben. Kommt vor allem bei Dingen wie Vektoren vor, die man in eine Map/Set steckt, ohne dass ihre Reihenfolge eine wichtige Rolle spielten.

Ich habe auch schon temporäre std::pair s erstellt, nur um solche Sortierfunktoren zu implementieren.

Wer hindert dich daran fürs pair ein typedef und für first & second entsprechende inline Wrapper funktionen zu schreiben? Das dauert nich mehr als 10 sekunden. Ich versteh das Problem nicht, egal ob du jetzt sarkastisch bist oder nicht.

In der Zeit haut man auch ne

struct FooBar
{
    int foo;
    int bar;
};

raus und hat gleich schönere Namen und weniger Template-Wirrwarr.

In der Zeit haut man auch ne

struct FooBar
{
    int foo;
    int bar;
};

raus und hat gleich schönere Namen und weniger Template-Wirrwarr.

Soweit ich mich recht entsinne müsstest du um die 100% kompatibilität mit den STL containern zu gewährleisten noch entsprechende constructoren und zuweisungs operator schreiben (http://msdn.microsoft.com/en-us/library/bb385469.aspx, gehen wir mal davon aus dass es sich nicht um simple Datentypen wie int handelt), da ist ein wrapping durchaus einfacher und fixer da bereits von natur aus gegeben (von der handhabung vllt nicht so elegant wie eine eigene Lösung aber die deutlichkeit ist equivalent).

Ethon schrieb:

In der Zeit haut man auch ne

struct FooBar
{
    int foo;
    int bar;
};

raus und hat gleich schönere Namen und weniger Template-Wirrwarr.

Soweit ich mich recht entsinne müsstest du um die 100% kompatibilität mit den STL containern zu gewährleisten noch entsprechende constructoren und zuweisungs operator schreiben (http://msdn.microsoft.com/en-us/library/bb385469.aspx, gehen wir mal davon aus dass es sich nicht um simple Datentypen wie int handelt), da ist ein wrapping durchaus einfacher und fixer da bereits von natur aus gegeben (von der handhabung vllt nicht so elegant wie eine eigene Lösung aber die deutlichkeit ist equivalent).

Dass die entsprechende Klassen diese Funktionen haben müssen, bedeutet nicht per se, dass man sie selbst schreiben muss oder auch nur sollte. In bestimmten Fällen der obigen Art könnte es erforderlich sein, den Zuweisungsoperator selbst zu implementieren, wenn starke Exceptionsicherheit erforderlich ist und das zweite Element bei der Zuweisung werfen kann. Das dürfte aber nicht die Regel sein.

The header <utility> also overloads the relational operators ==, <, !=, >, >= and <= , so as to be able to compare pair objects of the same type directly

Das meinte ich ja im OP damit, dass Operatoren bereits angeboten werden.

knivil:
Ok, sorry. Ich hatte Dich erst so verstanden, dass es um einen vector typisiert mit einer struct geht, das zwei Datenelemente hat, nicht um einen vector mit zwei Elementen. Letzteres mit pair zu vergleichen macht natürlich keinen Sinn...

ich habe jetzt häufiger Mal std::pair genutzt, wenn ich z.B. einen vector mit exakt zwei Elementen haben wollte.

Dann hätte ich eher an std::array<T,2> gedacht.

Eisflamme schrieb:

Wann nutzt ihr pair?

Eigentlich nur dann, wenn ich std::map verwende. Sonst fallen mir bessere Namen mit mehr Aussagekraft für eigene Typen ein. Jedenfalls fällt mir gerade keine andere Situation ein, wo ich pair benutze.

Könnte Dich interessieren, Tachyon:
Pairs do not make good ranges.

Das das nicht garde toll ist, ist mir auch ohne Artikel klar aber boost.range nimmt halt ein pair an, um nicht direkt kompatible Iteratorpaare zu wrappen. Alleine, dass man mit Pair ein Ding hat, dass <T,U> ermöglicht, obwohl man eigentlich <T,T> haben will, spricht schon Bände.