mein std::vector spielt verrückt
-
Spartaner schrieb:
das vector nicht sortiert ist mir bekannt. Allerdings muss auch nicht sortiert werden, da die Elemente in der Reihenfolge wie ich sie in den vector packe sortiert sind und auch so bleiben. Allerdings kann ich natürlich auch ein multiset nehmen.
Ist dir auch bekannt, daß equal_range eine sortierte Grundmenge erwartet?
-
@ Simon2: zu deinem Beispiel. Das ist mir schon klar, wo der first und der second iterator hin zeigt. Bloß da die Objekte ja so wie in meinem Codeschnipsel gezeigt, sortiert vorliegen, sollte doch alles funktionieren. Siehe deine Version 1. Genau dass möchte ich ja haben.
pos: LFGT
ship_range.first: SFGT
ship_range.second: SFGT
LFGT: 01. Schleifendurchlauf, pos zeigt auf LFGT. Doch warum zeigt schip_range.first auf SFGT und nicht auf LFGT? und auch .second ist falsch. Er müsste ja auf ein Element nach dem letzten LFGT zeigen, also hier ins leere.
Noch ein kleiner Trick: Du kannst Iteratoren auch einfach subtrahieren und Du bekommst die Anzahl der Elemente dazwischen.... die letzte "Zählschleife" brauchst Du also nicht.
Danke! Ist ja auch logisch, aber man macht sich ja immer mehr arbeit als nötig
Ich werde es jetzt einfach mal mit einem multiset versuchen. So wie es aussieht, dürfte es damit dann ja funktionieren, hoffe ich doch.
Gruß Spartaner
-
Hi,
nochmal eine Frage: Wie "funktioniert" bei Dir "id" ?
Wie wird das gefüllt ? Wenn Du da irgendwelche "Spielchen mit statics" machst - sind die "copy-safe" ?Gruß,
Simon2.
-
Mit dem multiset funktioniert es wunderbar.
Aber ich möchte doch noch verstehen, warum es mit dem vector nicht funktioniert hat. Wenn die Objekte im vector jetzt nicht sortiert wären, bräuchte man nicht mehr drüber diskutieren. Dass es dann nicht funktioniert ist klar. Aber da die Elemente ja sortiert vorliegen, verstehe ich es nicht. Oder verstehe ich den Begriff "Sortiert" falsch?
1. 111222333444555666777
2. 222111444333555777666
3. 123134732452346473452
1. Ist ja ganz klar sortiert. Identische Elemente sind direkt nebeneinander und es ist nach größe geordnet.
2. Zählt dies jetzt auch als sortiert oder als unsortiert? Identische Objekte sind zwar nebeneinander, aber die unterschiedlichen typen sind nicht nach Größe sortiert. Meiner Meinung nach müsste mir equal_range aber trotzdem das richtige Iteratorpaar liefern. Wo ich hier aber wohl falsch liege.
3. dazu brauche ich wohl nichts sagen
Gruß Spartaner
-
id wird im Konstruktor der c_ship-Klasse gesetzt. Je nach Typ (sfgt, wadr...) habe ich sie einfach durchnummeriert.
-
"Sortiert" aus Sicht der STL bedeutet "aufsteigend geordnet" (gemäß deiner Definition von <). Also solange du von der Standard-Implementierung ausgehst, ist die zweite Reihe nicht sortiert.
-
Spartaner schrieb:
2. Zählt dies jetzt auch als sortiert oder als unsortiert?
Unsortiert.
-
Spartaner schrieb:
id wird im Konstruktor der c_ship-Klasse gesetzt. Je nach Typ (sfgt, wadr...) habe ich sie einfach durchnummeriert.
Hi,
das heißt, der "type" sfgt bekommt immer die id 1, wadr die id2, .... ?
Dann könntest Du das Ganze ja auch mit type statt mit id machen - oder möchtest Du da Performance sparen ?Gruß,
Simon2.
-
@CStoll und MFK: Dann ist mir jetzt auch absolut verständlich, warum es nicht funktioniert hat. Ich habe das 2. immer als sortiert betrachtet.
@Simon2: Ja, die einzelnen Typen haben immer die gleiche id. Und ja, das könnte ich auch mit dem type machen. Anfangs hatte ich es auch damit gemacht. Bloß da ich einfach nicht mehr wusste, woran der Fehler liegen könnte, wollte ich den vergleich mal mit einem einfachen int statt einem string machen.
Also mit Perfomance hat es hier weniger zu tun. Es war eher die pure Verzweiflung
Aber wo du gerade von Performance sprichst, machst sich dies so stark bemerkbar?
Gruß Spartaner
-
Spartaner schrieb:
...
Aber wo du gerade von Performance sprichst, machst sich dies so stark bemerkbar?Gruß Spartaner
Das kann man eigentlich nur durch Messungen herausbekommen. Wenn Du bislang keine Performanceprobleme gespürt hast, würde ich mir die Mühe sparen - das kann man auch noch nachträglich optimieren (und dann besser/zielgerichteter).
Spartaner schrieb:
@CStoll und MFK: Dann ist mir jetzt auch absolut verständlich, warum es nicht funktioniert hat. Ich habe das 2. immer als sortiert betrachtet....
Na ... immerhin hast Du einen "operator<" implementiert (und keinen operator==) - hätte ein Hinweis darauf sein können, nach welchem Kriterium und wie er vergleicht
...Um Dir noch einen kleinen Tipp zu geben: Es gibt auch std::count und std::count_if() ....
Gruß,
Simon2.
-
Simon2 schrieb:
Das kann man eigentlich nur durch Messungen herausbekommen
Das passt jetzt zwar nicht mehr ganz zum Thema, aber wie wird sowas eigentlich gemessen?
-
Spartaner schrieb:
Simon2 schrieb:
Das kann man eigentlich nur durch Messungen herausbekommen
Das passt jetzt zwar nicht mehr ganz zum Thema, aber wie wird sowas eigentlich gemessen?
Oh - "das ist ein weiters Feld". Angefangen vom persönlichen Empfinden des Users bis hin zu Zeit- und Häufigkeitsmessungen ("Profiling") auf Ebene der einzelnen Methodenaufrufe. Dabei ist eigentlich eher die Schwierigkeit, die richtigen Messpunkte und -szenarien zu finden. An den Messpunkten kann man dann mit den Sachen in ctime (v.A. time() ) Start- und Endzeitpunkt feststellen und die Differenz messen.
BTW: hast Du meinen Hinweis auf die std::count's gesehen ?
Gruß,
Simon2.
-
Ok, also dass klingt dann doch ziemlich umfangreich.
Ja, hab deinen Hinweis gesehen. Habe ich auch schonmal gehört, musste aber doch erst nochmal nachschlagen, da ich dies bisher auch noch nicht genutzt habe.
Zum zählen der Elemente ist es sicherlich hilfreich. Ich benötige allerdings das Iteratoren-Paar. Das Zählen habe ich nur eingbaut um zu überprüfen ob es so funktioniert wie es soll.
Gruß Spartaner
-
Spartaner schrieb:
...Ich benötige allerdings das Iteratoren-Paar. Das Zählen habe ich nur eingbaut um zu überprüfen ob es so funktioniert wie es soll.
Gruß Spartaner
Ach so !!
OK, dann hast Du mit equal_range() ja schon genau das, was Du brauchst.Gruß,
Simon2.