std::set

[Tachyon]

unreg schrieb:

SeppJ schrieb:

Da dein Kriterium ja anscheinend nicht das Ordnungskriterium des sets ist

Doch doch, ist es. Daher ja die Frage.

Ne, ist es nicht. Wenn Dein Elementtyp z.B. A ist und u und v Objekte vom Typ A , dann ist aus Sicht des sets u < v das Ordnungsmerkmal. Es werden also Objekte vom Typ A in Relation gesetzt. Dass intern ein String für den operator< benutzt wird, kann std::set nicht wissen. Das kann nur A-Objekte miteinander vergleichen.

[unreg]

Soweit war ich irgendwie auch schon..
Die Frage war, ob es trotzdem eine Möglichkeit gibt die schnelle Suche des set auszunutzen, undzwar möglichst elegant mit Standardmitteln.

[Tachyon]

unreg schrieb:

Soweit war ich irgendwie auch schon..
Die Frage war, ob es trotzdem eine Möglichkeit gibt die schnelle Suche des set auszunutzen, undzwar möglichst elegant mit Standardmitteln.

Wieso fragst Du noch mal? Das wurde schon zwei mal beantwortet.

[daddy_felix]

Das klingt fast so, als würdest du eine std::map wollen...

[unreg]

daddy_felix schrieb:

Das klingt fast so, als würdest du eine std::map wollen...

Das ist auch so, nur gehört der Key dem gemappten Objekt. Vielleicht könnte man eine Referenz benutzen, aber das Objekt kann ja im Speicher verschoben werden, insofern halte ich das für keine gute Idee.
Mich wundert auch etwas, dass dieses Problem noch nie jemand gehabt zu haben scheint.

[daddy_felix]

achso, dieser key ändert sich - dann geht eine map natürlich nicht.

Alle, die dieses Problem bisher gehabt haben, werden std::find_if verwendet haben (oder das Verhalten von find_if nachprogrammiert). Wieso hast du denn so ein Problem mit dieser Lösung?

[unreg]

Weil es den Sinn des set (die schnelle Suche) kaputt macht.

[daddy_felix]

Es *kann* keine schnelle Suche geben, wenn sich der entscheidende Key ändert. hast du mal geprüft, ob sich das "langsame" find_if überhaupt auf die Performance auswirkt?

[SeppJ]

Stopf alles in einen vector. Dazu dann noch eine jeweils map Ordnung nach Kriterium A auf Vectorindizes und eine map nach Kriterium B auf Indizes. Dann kannst du flott auf Daten nach unterschiedlicher Ordnung zugreifen. Alles schön in eine Supercontainerklasse gepackt.

Gibt's glaube ich auch schon fertig von Boost.

[daddy_felix]

SeppJ schrieb:

Stopf alles in einen vector. Dazu dann noch eine jeweils map Ordnung nach Kriterium A auf Vectorindizes und eine map nach Kriterium B auf Indizes. Dann kannst du flott auf Daten nach unterschiedlicher Ordnung zugreifen. Alles schön in eine Supercontainerklasse gepackt.

das klingt ja an sich gut, allerdings muss er dann darauf achten, die Map zu aktualisieren, wenn sich der Key eines Elementes ändert... oder habe ich da jetzt einen Denkfehler?

[Braunstein]

Kein Denkfehler. Deswegen sprach SeppJja auch davon alles in eine Verwaltungsklasse zu stopfen. Duie übernimmt dann die Synchronisation.

[daddy_felix]

und woher weiß die Verwaltungsklasse, dass sich in irgendeinem Objekt eine Membervariable geändert hat? Dazu müsste ja entweder das Objekt ein Signal aussenden oder die Verwaltungsklasse permanent die Member abfragen - und diese Member müssten dann auch öffentlich verfügbar sein.

[Braunstein]

Nein, deine Membervariablen machst du natürlich private. Nur die Verwaltungsklasse selbst bekommt die Rechte da was zu ändern. Du musst halt alle nötigen Zugriffsfunktionen implementieren.

[daddy_felix]

Wenn es sich dabei um ein eigenes Objekt handelt, ok. Wenn man Objekte aus einer Library verwalten will, geht das schon nicht mehr. Und mir ist immer noch nicht klar, wie die Synchronisation laufen soll, wenn da Objekt keine Signale bei Änderungen des Wertes aussendet. Geht das auch anders als mit permanentem Polling? Was, wenn die Klasse nicht Thread-sicher ist?