Besseres set gesucht?

Michael E. schrieb:

KasF: Ich verstehe ehrlich gesagt das Problem nicht.

Vermutlich hat mir etwas zwischen den Zeilen nicht gepasst. Egal, jetzt ist alles wieder gut

Eisflamme

Das du absichtlich die Problemstellung hier verkompliziert darstellst, hilft auch keinem weiter.

Du wolltest die genauen Details, die sind so. Das ist keine verkomplizierte Darstellung, das set steckt in einem Kontext, der eben nicht vollkommen trivial ist. Und ein Kontext, in dem mir jede Berechnung, die ich über ein Bit-und/oder/xor/nicht statt eine Schleife lösen kann, einen enormen Performance-Boost bringt (und nochmal: das hat nichts mit premature optimization zu tun, ich hatte die andere Variante und sie war zu langsam, weil es einige 10.000e oder 100.000e [je nach Eingabe] Berechnungen pro Sekunde sind) kann halt auch Mal komplexer sein, thematisches Wissen erfordern usw. Soll ich das hier ernsthaft breittreten, obwohl ich genau die Art von Antwort, die ich suche, gefunden habe?

Aussagen wollte ich damit nur: Wenn ich die Details jetzt hier alle breittrete, wird es ein Roman. Und ich habe bereits Lösungen, die:
- mein Problem exakt lösen
- mein Design deutlich sauberer machen

Nun denn, du scheinst und warst noch nie an einem anderen Design interessiert. Du hattest ein C++ Problem und wolltest genau die Lösung dazu erhalten. Fur saubere Softwareentwicklung wie du es geschrieben hast, bist du resistent.

Jup, glaub, was Du willst.

Vermutlich hat mir etwas zwischen den Zeilen nicht gepasst. Egal, jetzt ist alles wieder gut

Na dann ist ja gut.

An den Rest: vielen Dank für die Hilfe, ich habe das gesucht, was ich gefunden habe, bin mir darüber bewusst, dass ich jetzt anhand meines Kontextes noch das für mich Beste auswählen muss, aber meine Frage wurde super beantwortet.

hustbaer

Kellerautomat schrieb:

Ne. std::set ist einfach nicht fuer mehr als "ist X in M?"-Spielereien geeignet.

Lustigerweise nimmt man dafür dann doch eher ein unordered_set.

Nene, std::set ist schon für Fälle wo man etwas sortiert vorliegen haben möchte.

Ethon

Der Zweck von std::set ist für mich, eine Liste von geordneten, einzigartigen Werten zu haben.

Eisflamme

Hi,

also ich habe mir boost::multi_index_container jetzt Mal angeschaut und gefällt mir sehr. Löst mein Problem eigentlich perfekt und funktioniert wie ein set. Man könnte meinen, wir hätten hier eigentlich "ein besseres Set" (nicht limitiert auf ein Set, aber die Funktionalität eines Sets anbietend und verbessernd)
Auf der anderen Seite hat das Ding natürlich gewissen Overhead (vernachlässigbar in meinem Fall, schätze ich). Findet ihr, dass set dann überhaupt noch eine Daseinsberechtigung hat (wenn man davon absieht, dass boost != Standard)?

Ethon

Eisflamme schrieb:

Hi,

also ich habe mir boost::multi_index_container jetzt Mal angeschaut und gefällt mir sehr. Löst mein Problem eigentlich perfekt und funktioniert wie ein set. Man könnte meinen, wir hätten hier eigentlich "ein besseres Set" (nicht limitiert auf ein Set, aber die Funktionalität eines Sets anbietend und verbessernd)
Auf der anderen Seite hat das Ding natürlich gewissen Overhead (vernachlässigbar in meinem Fall, schätze ich). Findet ihr, dass set dann überhaupt noch eine Daseinsberechtigung hat (wenn man davon absieht, dass boost != Standard)?

Ich denke dass ein set ungefähr so viel Daseinsberechtigung hat wie zb die Permutations-Algorithmen.
Es ist einfach eine grundlegende Datenstruktur, die mMn in die STL gehört.

Eisflamme

Dann frage ich anders: Wieso sollte man jemals set<T> statt multi_index_container<T> verwenden, wenn man beide Möglichkeiten hat und kein Problem damit hat boost als stets verfügbare Bibliothek anzusehen?

Würde ich verstehen, wenn man die multi_index_container-Vorteile nicht braucht und set dann in manchen Fällen wirklich etwas schneller ist, weil mic mehr Overhead hat, aber da muss ich einfach fragen, ob sich der Performance-Unterschied eurer Erfahrung nach in Größenkategorien bewegt, die für 99% der auch performance-kritischen Fälle relevant sind oder nicht.

Oder vielleicht geht die Compilezeit ordentlich hoch oder so?

Edit:
also wenn ich mic einfach nur instanziiere und zwar mit int (!!) und überhaupt nicht benutze, dann dumpt QT beim Setzen eines Dialogtitels (und ein paar anderen Settern), weil ein interner Pointer plötzlich 0xcdcdcdcd ist... (und der Dialogtitel ist ein fixer String, der zu nichts in irgendeiner Abhängigkeit steht). Es hat nicht zufällig jemand eine superschlaue Kristallkugel-Vermutung, woran so etwas liegen kann? Das ist ja mega-seltsam, ich fass das Teil echt nicht an, ist nur ein neues Attribut meiner Klasse.

hustbaer

Oder vielleicht geht die Compilezeit ordentlich hoch oder so?

Ja, tut sie.
Die Programmierzeit geht auch ordentlich hoch - die Anwendung von Boost.MultiIndex ist doch wesentlich auswendiger als einfach mal schnell std::set<T> zu tippen.

Eisflamme

Na ja, ich will es ja auch nur mit einem einzelnen Index arbeiten. Ich habe mir jetzt Mal das Einsteiger-Tutorial von der boost-Seite durchgelesen, also die Hälfte davon.

Trotzdem erhalte ich weiterhin wirklich sinnlose Fehler, als würde ich allein durch die Instaziierung eines multi_index_containers undefiniertes Verhalten erzeugen. Der Container sorgt aber nur in einer Klasse als Attribut für Kummer. Instanzen der Klasse werden häufiger Mal kopiert und auch mit copy-ctor& instanziiert. Kann das irgendwie bei einem leeren Container problematisch sein?

Wenn ich eine Instanz einfach in einer ÜE im global space anlege, passiert hingegen nichts, wie man es erwarten sollte.

Ich bin irritiert...

hustbaer

Bei mir haben die immer gut funktioniert.
Hab aber auch nie welche rumkopiert.

Eisflamme

Na ja, jedenfalls ist mir das zu seltsam. Ich finde auch über Google nichts dazu. Eigentlich sollte es ja nun auch wirklich keinen Namenskonflikt oder so geben, das wäre für mich die einzige Erklärung. using namespace boost; oder solche Späße habe ich definitiv nicht im Header der Klasse.

Jetzt habe ich noch boost::set gefunden:
http://www.boost.org/doc/libs/1_53_0/doc/html/boost/container/set.html

Nach Abstieg in die Tiefen der Header fand ich jedoch heraus, dass der Iterator vom tree auch vom const_iterator erbt, also hilft das nicht. Wieso baut boost das set nach? Falls irgendeine Implementierung eines Compilers kaputt ist und man eine Ausweichmöglichkeit hat oder wie?

hustbaer

http://www.boost.org/doc/libs/1_53_0/doc/html/container/history_and_reasons.html#container.history_and_reasons.Why_boost_container

Eisflamme

Hi,

hustbaer:
Danke, jetzt verstehe ich mehr!

Wollte nur kurz schreiben, dass es mit boost1.53 jetzt geht, da der mehr Compilerfehler anzeigt. Es gab ein paar Konflikte, z.B. std::move und boost::move (aber das kam eh später dazu, also war das vorher wohl egal) und v.a. hat QT mit boost rumgemeckert, sodass ich ein #define QT_NO_KEYWORDS setzen musste.

Jetzt klappt es zumindest wie ein Set. modify wird dann eingebaut.

Noch eine Rückfrage:

Die Programmierzeit geht auch ordentlich hoch - die Anwendung von Boost.MultiIndex ist doch wesentlich auswendiger als einfach mal schnell std::set<T> zu tippen.

Das verstehe ich bei einem einzelnen Index nach wie vor nicht. Ich meine:

boost::multi_index_container<T>

entspricht ja:

boost::multi_index_container<
    T,
    indexed_by<
        ordered_unique<identity<T>>>>

Und für Index0-Zugriff kann ich ja direkt auf der Instanz des Containers die gleichen Methoden nutzen wie bei einem set. Habe zunächst nur mein typedef geändert (und die Includes und das QT-Makro) und es klappt und kann jetzt lustige Dinge wie modify einbauen oder später einen Index nachbauen.

Also ich sehe da auch aus Programmier-Aufwands-Sicht gerade nur Vorteile, was meinst Du denn genau? Vielleicht übersehe ich etwas Tödliches.

hustbaer

OK, in so einfachen Fällen hab ich Multi-Index noch nie verwendet.
Und in den nicht-so-einfachen Fällen gibt es da schon einiges an Doku zu lesen...