<![CDATA[std::set::find-Problem]]>Halli hallo!
Leider bin ich auf Probleme bei der Anwendung von std::set gestoßen.
Und zwar habe ich verschiedene Objekte mit einem gemeinsamen Interface, welche nur auf dem Heap existieren können und per boost::shared_ptr referenzgezählt werden. Zudem ist allen gemein, dass sie ein Namens-Attribut besitzen (über die gesamte Lebenszeit der Objekt konstant), welches als Schlüssel beim Suchen fungiert. Nun ist ja an sich eine normale Herangehensweise, dass man diese Objekte in eine std::map verfrachtet. Allerdings bedeutet das in meinem Fall, dass ich dieses Vergleichattribut unnötig duplizieren müsste. Also habe ich mir gedacht, ich packe sie in ein std::set mit einem benutzerdefinierten Vergleichs-Objekt. Das funktioniert allerdings nur schön, bis man im set dann mal ein Objekt mit dem zugehörigen Schlüssel suchen muss. Denn leider gibt es bei std::set::find keine Möglichkeit, beispielsweise einen Funktor mitzugeben, der aus dem im set gespeicherten Zeiger den Schlüssel extrahiert und mit einem gegebenen Schlüssel vergleicht. std::find_if hingegen dürfte ja meinem Wissen nach nicht von der bereits sortierten Datenstruktur des sets profitieren.

Also meine Frage: Gibt es irgendwie eine Möglichkeit, die effiziente Suche in einem set so anzupassen, dass das zu vergleichende Objekt nicht vom Typ der im set gespeicherten Objekte sein muss (d.h. dass ich derefenzieren und eine Methode aufrufen kann, um sie kompatibel zu machen).

Viele Grüße,
Michael

]]>https://www.c-plusplus.net/forum/topic/232973/std-set-find-problemRSS for NodeSat, 04 Apr 2026 21:35:34 GMTThu, 29 Jan 2009 16:20:09 GMT60<![CDATA[Reply to std::set::find-Problem on Thu, 29 Jan 2009 16:20:09 GMT]]>Halli hallo!
Leider bin ich auf Probleme bei der Anwendung von std::set gestoßen.
Und zwar habe ich verschiedene Objekte mit einem gemeinsamen Interface, welche nur auf dem Heap existieren können und per boost::shared_ptr referenzgezählt werden. Zudem ist allen gemein, dass sie ein Namens-Attribut besitzen (über die gesamte Lebenszeit der Objekt konstant), welches als Schlüssel beim Suchen fungiert. Nun ist ja an sich eine normale Herangehensweise, dass man diese Objekte in eine std::map verfrachtet. Allerdings bedeutet das in meinem Fall, dass ich dieses Vergleichattribut unnötig duplizieren müsste. Also habe ich mir gedacht, ich packe sie in ein std::set mit einem benutzerdefinierten Vergleichs-Objekt. Das funktioniert allerdings nur schön, bis man im set dann mal ein Objekt mit dem zugehörigen Schlüssel suchen muss. Denn leider gibt es bei std::set::find keine Möglichkeit, beispielsweise einen Funktor mitzugeben, der aus dem im set gespeicherten Zeiger den Schlüssel extrahiert und mit einem gegebenen Schlüssel vergleicht. std::find_if hingegen dürfte ja meinem Wissen nach nicht von der bereits sortierten Datenstruktur des sets profitieren.

Also meine Frage: Gibt es irgendwie eine Möglichkeit, die effiziente Suche in einem set so anzupassen, dass das zu vergleichende Objekt nicht vom Typ der im set gespeicherten Objekte sein muss (d.h. dass ich derefenzieren und eine Methode aufrufen kann, um sie kompatibel zu machen).

Viele Grüße,
Michael

]]>https://www.c-plusplus.net/forum/post/1654470https://www.c-plusplus.net/forum/post/1654470Thu, 29 Jan 2009 16:20:09 GMT<![CDATA[Reply to std::set::find-Problem on Thu, 29 Jan 2009 16:22:45 GMT]]>Guck Dir mal den Ctor von std::set an.

]]>https://www.c-plusplus.net/forum/post/1654472https://www.c-plusplus.net/forum/post/1654472Thu, 29 Jan 2009 16:22:45 GMT<![CDATA[Reply to std::set::find-Problem on Thu, 29 Jan 2009 16:30:11 GMT]]>Danke für die rasche Antwort.
Leider ist das ja das Problem. Ich benutze ja bereits dieses benutzerdefinierte Vergleichsobjekt (es dereferenziert die gespeicherten Zeiger, und vergleicht dann die Attribute). Nur hilft mir dass nicht weiter, weil ich bei set::find (oder einer ähnlich effizienten Alternative) ja den Schlüssel mitgeben möchte, und nicht einen Zeiger auf ein Objekt, welches diesen Schlüssel besitzt. Allerdings möchte set::find ein Objekt des gespeicherten Typs haben und es gibt leider keine template-Variante, die einen weiteren (verschiedenen) Funktor akzeptiert.

Viele Grüße,
Michael

]]>https://www.c-plusplus.net/forum/post/1654475https://www.c-plusplus.net/forum/post/1654475Thu, 29 Jan 2009 16:30:11 GMT<![CDATA[Reply to std::set::find-Problem on Thu, 29 Jan 2009 16:37:15 GMT]]>Decimad schrieb:

Also meine Frage: Gibt es irgendwie eine Möglichkeit, die effiziente Suche in einem set so anzupassen, dass das zu vergleichende Objekt nicht vom Typ der im set gespeicherten Objekte sein muss (d.h. dass ich derefenzieren und eine Methode aufrufen kann, um sie kompatibel zu machen).

Hallo Michael,

ich glaube, dass es diese Möglichkeit nicht gibt. Entweder Du nimmst eine std::map oder Du konstruierst eine Dummy-Klasse, die auch von Deinem besagten Interface abgeleitet ist und nur den Namen unterstützt. Ich unterstelle dabei , dass Dein set etwa so aussieht:

std::set< boost::shared_ptr< ICommonInterface > >

Gruß
Werner

]]>https://www.c-plusplus.net/forum/post/1654482https://www.c-plusplus.net/forum/post/1654482Thu, 29 Jan 2009 16:37:15 GMT<![CDATA[Reply to std::set::find-Problem on Thu, 29 Jan 2009 16:46:51 GMT]]>Hallo Werner!
Vielen Dank, ich befürchtete das schon. Aus den Eigenschaften der Objekte, die diese Schnittstelle implementieren, würde leider folgen, dass ich jedes Mal eines Deiner vorgeschlagenen "Proxy"-Objekte auf dem Heap konstruieren müsste. Daher werde ich wieder den "Weg des geringsten Widerstandes" aka. std::map beschreiten. 🙂

Viele Grüße,
Michael

PS: Wobei ich natürlich auch ein temporäres Objekt auf dem Stack erstellen könnte und einen shared_ptr mit null_deleter darauf zeigen lassen könnte. Aber... hmmm... naja 🙂

]]>https://www.c-plusplus.net/forum/post/1654489https://www.c-plusplus.net/forum/post/1654489Thu, 29 Jan 2009 16:46:51 GMT<![CDATA[Reply to std::set::find-Problem on Thu, 29 Jan 2009 17:07:54 GMT]]>Hallo Michael,

eine - zumindest theoretische Möglichkeit - wäre, einen Wrapper zu bauen, der aus einem Namen und besagten shared_ptr besteht. Bei Deinem Objekten ist der Name leer. Beim Vergleichsobjekt ist der Name gefüllt und der shared_ptr leer. Dann hast Du einen set< Wrapper > und passt die Vergleichsmethode entsprechend an, so dass dort immer der richtige Name gewählt wird.

Auf das Interface greifst Du zu, indem Du eine Funktion

ICommonInterface* get_pointer( Wrapper& wrapper )

schreibst. Dann kannst Du zumindest mit der Kombination von Algorithmen und boost:bind, wie gewohnt auf die Elemente zugreifen, als ob es sich um shared_ptr handelt. (siehe dazu http://www.boost.org/doc/libs/1_37_0/libs/bind/mem_fn.html die Stelle 'Library authors can "register" their smart pointer classes ...')

Gruß
Werner

]]>https://www.c-plusplus.net/forum/post/1654512https://www.c-plusplus.net/forum/post/1654512Thu, 29 Jan 2009 17:07:54 GMT<![CDATA[Reply to std::set::find-Problem on Fri, 30 Jan 2009 19:05:55 GMT]]>Da habe ich doch glatt Deine letzte Antwort verpasst!
Das wäre selbstverständlich auch eine gangbare Alternative; das merke ich mir auf jeden Fall für Situationen vor, in denen ich wirklich nur mit absolut schlechtem Gewissen den Schlüssel für einen std::map duplizieren würde. Ich hatte mir auch überlegt, dass mann dann evtl. einen id-proxy (Irgendwie mag ich das wort proxy :D) als Schlüssel in der map einsetzen könnte, dessen Konstruktion für eine etwaige Suche zumindest einfacher handhabbar ist (weil die Einschränkungen aufgrund der Schnittstelle der gespeicherten Objekte damit wegfallen). Das könnte sich dann unter Umständen bei sehr komplizierten Schlüsseln lohnen. Einen Vergleich mit Deinem Ansatz habe ich aber noch nicht vollständig gezogen.
Nachdem ich nochmal darüber geschlafen habe, war es mir dann heute relativ egal, dass ich lieber auf std::set gesetzt hätte 🙂

Vielen Dank und beste Grüße,
Michael

]]>https://www.c-plusplus.net/forum/post/1655174https://www.c-plusplus.net/forum/post/1655174Fri, 30 Jan 2009 19:05:55 GMT