std::shared_ptr vergleichen

MatheStein

Hey Leute,

kann man es irgendwie elegant schaffen, dass 2 std::shared_ptr s_ptr1, s_ptr2 gleich sind, d.h. s_ptr1 == s_ptr2, genau dann wenn *s_ptr1 == *s_ptr2?

Das heißt die Pointer sollen genau dann gleich sein bzgl "==", wenn die durch sie referenzierten Objekte bzgl "==" gleich sind (sofern "==" für sie definiert)

Gruß

SeppJ

In welchem Zusammenhang? Du willst doch sicherlich irgendwo eine Vergleichsfunktion angeben, so wie das klingt. Dann gib doch einfach diese Art von Vergleich an, entweder als Funktion oder Lambaausdruck (je nach Standardversion).

krümelkacker

MatheStein schrieb:

kann man es irgendwie elegant schaffen, dass 2 std::shared_ptr s_ptr1, s_ptr2 gleich sind, d.h. s_ptr1 == s_ptr2, genau dann wenn *s_ptr1 == *s_ptr2?

Das heißt die Pointer sollen genau dann gleich sein bzgl "==", wenn die durch sie referenzierten Objekte bzgl "==" gleich sind (sofern "==" für sie definiert)

Das magst du im Moment für eine gute Idee halten, ist es aber nicht. Und zum Glück ist das auch nicht möglich, es sei denn, du definierst dir deine eigene Zeiger-Klasse, wovon ich aber abraten möchte.

Wo glaubst du, so ein Verhalten gebrauchen zu können?

nurf

template<class T, class U> inline bool operator==(shared_ptr<T> const & a, shared_ptr<U> const & b)
{
  // du bist dran
}

Nexus

@nurf: Wie schön, dass du die Hinweise der Vorposter ignorierst.

Ich kann mich krümelkacker nur anschliessen, das Gewollte macht keinen Sinn. Wenn man auf Objektgleichheit prüfen möchte, dereferenziert man eben. Was soll z.B. ein Vergleich mit Nullzeigern als Ergebnis haben? Undefiniertes Verhalten, weil automatisch dereferenziert wird? Es ist schon gut, dass der für std::shared_ptr überladene operator== die Semantik von rohen Zeigern übernimmt.

krümelkacker

nurf schrieb:

template<class T, class U> inline bool operator==(shared_ptr<T> const & a, shared_ptr<U> const & b)
{
  // du bist dran
}

Ich denke nicht, dass das funktionieren wird; denn shared_ptr definiert schon einen solchen Operator. Falls dieser auch als Template definiert wurde, müsste es eine Compiler-Fehlermeldung à la "ambiguous call" geben. Falls Dein Operator bei der Namensauflösung nicht gefunden wird oder shared_ptr den operator== als inline-friend definiert, hat dein Template gar keinen Effekt, weil der "richtige" Operator dann bei der Überladungsauflösung gewinnt.

So oder so, ist es immer noch eine schlechte Idee Die Semantik von operator== auf shared_ptr ist schon definiert, und die sollte man nicht ändern wollen.

Ich kann mir eher vorstellen, dass der Fragesteller auch mit einem benutzerdefinierten Predicate zufrieden zu stellen ist. Allerdings fehlt dazu noch mehr Information vom Fragesteller.

MatheStein

Danke für eure Hilfen

Wie schon von euch prophezeit gibt es eine elegantere Lösung War drauf und dran selbst eine Sortierung auf einem Vector aus shared_ptr zu programmieren, jedoch sollte die Sortierung bzgl. der referenzierten Objekte sein.

Nutze jetzt die std::sort Funktion

Besten Dank, Gruß und schönes Wochenende an alle

Nexus

Übrigens: vector<shared_ptr<T>> willst du meistens nicht. Eigentlich nur dann, wenn die Elemente wirklich geteilt werden, d.h. es gibt mehrere shared_ptr s auf ein Objekt.

Alternativen sind vector<T> (falls möglich), boost::ptr_vector<T> oder vector<unique_ptr<T>> .

Nexus schrieb:

Übrigens: vector<shared_ptr<T>> willst du meistens nicht. Eigentlich nur dann, wenn die Elemente wirklich geteilt werden, d.h. es gibt mehrere shared_ptr s auf ein Objekt.

Alternativen sind vector<T> (falls möglich), boost::ptr_vector<T> oder vector<unique_ptr<T>> .

Warum sollte man vector<shared_ptr<T>> nicht wollen? vector<unique_ptr<T>> ist nur eingeschränkt zu verwenden (z.B. kein Reserve).

Kellerautomat

Warum sollte Reserve nicht möglich sein?

ipsec

Pavilion schrieb:

vector<unique_ptr<T>> ist nur eingeschränkt zu verwenden (z.B. kein Reserve).

Selbstverständlich geht reserve. Und auch resize geht.