Besseres set gesucht?
-
Das klingt nach ausgezeichneten Vorschlägen, vielen Dank.
-
Eisflamme schrieb:
"Set, bei dem man etwas ändern kann? Das ergibt keinen Sinn."
Doch, weil nicht alle Teile der set-struct Schlüsselelemente sind und ich will Nicht-Schlüssel-Elemente ändern können. Dennoch will ich die Sortierung und den Aufbau des Sets gegeben haben.Boost MultiIndex unterstützt allgemein das Ändern von Objekten in einem Set, selbst wenn sich dadurch die Position ändern sollte:
http://www.boost.org/doc/libs/1_53_0/libs/multi_index/doc/reference/ord_indices.html#modifyUnd mit Intrusive-Containern funktioniert es natürlich auch.
-
KasF schrieb:
Wieviele Elemente steckst du in die set?
Und hast du schon geprofiled? Ebenfalls musst du auch nicht bei find und co durch den ganzen Baum wandern, deswegen ist es ja auch ein Baum. Kann es sein, dass du irgendwo einen Flaschenhals vermutest, wo keiner ist. Wie sagt man so schön "Premature optimization is the root oft evil". Natürlich ist es nicht schön das ganze Objekt auszutauschen, nur um einen Member zu ändern, aber das spielt gerade keine Rolle.
-
Ich arbeite gerade den ganzen Tag und hab dann immer Einfälle und die gebe ich hier zum Besten und suche nach Lösungen. Ich komme leider nicht immer direkt zum profilen oder dazu Dinge anders umzusetzen. Lernen und Entwicklung laufen etwas auseinander (aber fernab von disjunkt!).
Premature Optimization mache ich nicht, ich weiß genau, wo die Software zu langsam ist. Und premature ist da auch nichts, die Funktionalität steht schon in anderer Variante.
Nur ist es natürlicherweise unelegant, wenn ich Ändern durch Löschen + Einfügen bewerkstellige, das ist für mich einfach ein Konzeptfehler und den gedenke ich zu beheben, weil ich lieber elegant und sauber statt umständlich und dreckig code. Hältst Du das für nachvollziehbar?
Natürlich ist es nicht schön das ganze Objekt auszutauschen, nur um einen Member zu ändern, aber das spielt gerade keine Rolle.
Du meinst für Deine Vermutung oder für mich? Für mich spielt es nämlich in der Tat eine große Rolle!
-
Für die Vermutung meinte ich. Ich bin selbst auch kein Fan von der mutable Lösung, aber einen anderen Designvorschlag können wir auch nicht machen, da wir nicht wissen, was du modellieren möchtest. Das mit mutable ist jetzt halt nur eine programmatische Lösung, keine logische.
Vermutlich sind key1 und key2 aber die hole cards
-
Habt ihr mich alle auf Ignore?
Ich hab' gerade zwei andere Vorschläge abgeliefert die beide wunderbar funktionieren...
-
hustbaer:
Nein, tut mir Leid, ich hatte nur noch nicht Gelegenheit da reinzuschauen, da ich mit MultiIndex keine Erfahrung habe und dafür erst den Kopf freikriegen muss. Aber das sieht interessant aus und ich werde mir das definitiv noch anschauen!KasF & knivil:
Ich finde ehrlich gesagt nicht, dass es hier notwendig wäre das genaue Problem zu kennen. Shade of Mine und hustbaer haben das Problem gelöst, gute Wege aufgezeigt. Die mussten auch nicht wissen, was ich "genau" mache. Genau genug steht es imo im OP.Und die key-Dinger sind ein 13-Bit-Element, das die zwei Holecards ver-und-ed anzeigt und ein bool, der sagt, ob die suited sind. Der Value-Teil ist eine Suits-Klasse: die besteht aus einem 16-Bit, der Suits anzeigt, wobei jedes Bit für eine Kombination von zwei Suits steht, der Information und welche Suit-Klasse das ist (off-suited, suited, pair), zudem auch noch einen 16-Bit-Typ, der sagt, wie viele Suits hier maximal gesetzt werden dürfen. Hat das jetzt weitergeholfen? Ich denke nicht, da ich jetzt noch mehr dazu erklären müsste, schätze ich. Dann habe ich aber irgendwann den ganzen Programmkomplex hier in Foren-Form abgebildet. Dann würde das Forum meine gesamte Arbeit erledigen. Hätte zwar auch was, aber ich glaube, Einzelfragen sind sinnvoller.
Dankeschön jedenfalls
-
Shade und hustbaer hätten das mit Sicherheit besserer und sauberer lösen können, wenn sie in der Problemstellung stecken würden. Das du absichtlich die Problemstellung hier verkompliziert darstellst, hilft auch keinem weiter.
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.
-
KasF: Ich verstehe ehrlich gesagt das Problem nicht. Eisflamme hat eine präzise Frage zur Umsetzung seines Designs gestellt. Die Informationen waren ausreichen, um ihm eine genaue Antwort zu geben. Gut, das mit dem "map ist pöse langsam" (BTW @Eisflamme: eine binäre Suche ist auch nicht gerade cachefreundlich
) war etwas wirr, stört aber nicht weiter. Wenn du hier eine Frage stellst, willst du doch bestimmt auch nicht zuerst dein gesamtes Design vorstellen und rechtfertigen.
-
Das ist doch nur das übliche Säbelrassel hier: dir fällt keine lösung ein? Dann gibt es zwei möglichkeiten a) postuliere, dass ohne die genaue problemstellung das nicht gelöst werden kann oder b) dass das schon vom design/modellierung her ganz falsch klingt... Möglicherweise nebst überleitung zu a).
-
Ne. std::set ist einfach nicht fuer mehr als "ist X in M?"-Spielereien geeignet.
-
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
-
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 machenNun 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.
-
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.
-
Der Zweck von std::set ist für mich, eine Liste von geordneten, einzigartigen Werten zu haben.
-
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)?
-
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.
-
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.
-
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 schnellstd::set<T>zu tippen.
-
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...
