Nun wurde mir der Tipp gegeben, dass eine deque besser sein soll, da diese auch einen wahlfreien Zugriff erlaubt aber sie nicht in einem im Speicher stehen muss und somit beim Einfügen nicht immer komplett verschoben wird.
Dies hört sich sinnvoll an, weil im Vector mehrere 10.000 Einträge stehen können.

Nun wollte ich eure Erfahrung hören, ob sich deque wirklich anbieten hier, da mich vor allem der Satz
"For operations that involve frequent insertion or removals of elements at positions other than the beginning or the end, deques perform worse"
kann ich noch nicht ganz so viel anfangen. Ist dies allgemein gesprochen oder auch auf Vector vs. Deque bezogen?

Danke für eure Hilfe. Ich würde die verschiedenen Arten gerne besser verstehen, um sie zukünftig passend wählen zu können.

Wenn du aber binäre Suche machst, nehme ich an, dass der vector immer sortiert sein muss? Und deswegen wohl auch Einfügen in die Mitte, damit er sortiert bleibt? In dem Fall wäre eventuell ein set noch besser, das ist automatisch sortiert und Einfügen und Suchen geht jeweils in O(log n).

Die deque verteilt die Daten auf mehrere Blöcke, aber in denen ist jeweils eine feste Element-Anzahl, die ohne Lücken gefüllt wird. Wenn du dort ein Element einfügst, schiebst du ein anderes vorne oder hinten aus dem aktuellen Block heraus, das dann in den Nachbarblock eingefügt werden muß - und auf diese Weise werden dann doch alle Elemente bis zum nächstgelegenen Ende der deque umkopiert, um eine Lücke zu schaffen.

Wenn es dir wirklich um die Suchmöglichkeiten geht, solltest du eher einen Container nehmen, der schon von sich aus sortiert ist ((multi)set oder (multi)map). Bei denen muß beim Einfügen nichts umkopiert werden und die binäre Suche unterstützen sie auch direkt.

"For operations that involve frequent insertion or removals of elements at positions other than the beginning or the end, deques perform worse"
kann ich noch nicht ganz so viel anfangen. Ist dies allgemein gesprochen oder auch auf Vector vs. Deque bezogen?

Wenn du den ganzen Satz zitiert hättest, wäre auch klar, dass sich die Aussage auf Deque vs. Listen bezieht.

For operations that involve frequent insertion or removals of elements at positions other than the beginning or the end, deques perform worse and have less consistent iterators and references than lists.

CStoll schrieb:

Wenn es dir wirklich um die Suchmöglichkeiten geht, solltest du eher einen Container nehmen, der schon von sich aus sortiert ist ((multi)set oder (multi)map). Bei denen muß beim Einfügen nichts umkopiert werden und die binäre Suche unterstützen sie auch direkt.

Ja, ich will eine große Menge von Daten speichern (bei denen im Laufe der Zeit immer mehr dazu kommen und manche auch wieder entnommen werden) und darin nach speziellen Einträgen suchen.

Es ist im Moment auch die Stelle im Programm, die am langsamsten ist.

Ich habe es schon um einiges verschnellert, in dem ich die sequentielle Suche eingebaut habe.

Einen sortierten Container habe ich bis jetzt noch nicht verwendet, da die Elemente Objekte einer eigenen Klasse sind, bei denen intern irgend wo eine eindeutige ID gespeichert ist, nach der sortiert werden.
Nach dem gesuchten Eintrag wird gesucht, in dem ich sage, ich will das Element mit einer speziellen ID.

Wenn ich ein Set hernehmen will, muss ich denke ich einige Operatoren überschreiben, richtig? Ich geh davon aus, <, > und == für die eigene Klasse und die Operatoren für die ID-Klasse.
Würde das funktionieren? Denke das wäre effizienter wie mein selbstimplementierter "Container".

Ich hoffe ich versteht meine Frage, bin selbst gerade verwirrt
Versuche es bei Unverständlichkeit nochmals besser zu formulieren.

hustbaer schrieb:

C Anfänger schrieb:

"For operations that involve frequent insertion or removals of elements at positions other than the beginning or the end, deques perform worse"
kann ich noch nicht ganz so viel anfangen. Ist dies allgemein gesprochen oder auch auf Vector vs. Deque bezogen?

Wenn du den ganzen Satz zitiert hättest, wäre auch klar, dass sich die Aussage auf Deque vs. Listen bezieht.

For operations that involve frequent insertion or removals of elements at positions other than the beginning or the end, deques perform worse and have less consistent iterators and references than lists.

hm ja, da hast recht. Als ich es gelesen habe, hab ich gar nicht an den Container list gedacht, sondern dachte an lists als Überbegriff für container. Wie peinlich.

bool operator<(const ID& lhs, const ID& rhs)
{
  //Vergleich der ID-Werte
}

bool operator<(const element& lhs, const element& rhs)
{
  return lhs.getID() < rhs.getID();
}

das ist schon alles, was du benötigst, um die Werte in eine set<> eintragen zu können, die übrigen Vergleichsoperatoren sind Luxus. Ich würde eventuell noch einen operator== schreiben (set nutzt übrigens den < Operator zur Feststellung, was "gleich" ist) und den Rest mittels std::rel_ops dazuholen.

Insertions die ziemlich gut in der Mitte liegen können dagegen bei std::deque langsamer sein, aber auch viel schneller als bei std::vector . Kommt drauf an wie die std::deque intern implementiert ist. Bei der MSVC Implementierung z.B. ist die "Seitengrösse" abhängig von sizeof(T) , und wenn das gross genug ist werden "Seiten" aus nur einem einzigen Element verwendet. In dem Fall sollten Insertions schneller sein als bei std::vector , vorausgesetzt die Implementierung "erkennt" dass nur der Zeiger-Table verändert werden muss.

CStoll schrieb:

set nutzt übrigens den < Operator zur Feststellung, was "gleich" ist

rein interessehalber: wie kann man mit einem < Operator die Gleichheit feststellen?

hustbaer schrieb:

@C Anfänger:
BTW: Insertions nahe dem Anfang sollten bei std::deque mMn. immer schneller sein als bei std::vector .

Insertions die ziemlich gut in der Mitte liegen können dagegen bei std::deque langsamer sein, aber auch viel schneller als bei std::vector . Kommt drauf an wie die std::deque intern implementiert ist. Bei der MSVC Implementierung z.B. ist die "Seitengrösse" abhängig von sizeof(T) , und wenn das gross genug ist werden "Seiten" aus nur einem einzigen Element verwendet. In dem Fall sollten Insertions schneller sein als bei std::vector , vorausgesetzt die Implementierung "erkennt" dass nur der Zeiger-Table verändert werden muss.

danke für den hinweis.

rein interessehalber: wie kann man mit einem < Operator die Gleichheit feststellen?

a == b <==> !(a < b) && !(b < a) .

Tatsächlich kann man ausschließlich mit dem < -Operator und den logischen Verknüpfungen sämtliche anderen Vergleichsoperatoren herleiten, vorausgesetzt der Operator erzeugt eine strenge Totalordnung.

C Anfänger schrieb:

rein interessehalber: wie kann man mit einem < Operator die Gleichheit feststellen?

a == b <==> !(a < b) && !(b < a) .

Tatsächlich kann man ausschließlich mit dem < -Operator und den logischen Verknüpfungen sämtliche anderen Vergleichsoperatoren herleiten, vorausgesetzt der Operator erzeugt eine strenge Totalordnung.

das ist gut
muss ich mir merken fürs nächste mal, auch wenns grad offtopic ist

C Anfänger schrieb:

rein interessehalber: wie kann man mit einem < Operator die Gleichheit feststellen?

a == b <==> !(a < b) && !(b < a) .

Tatsächlich kann man ausschließlich mit dem < -Operator und den logischen Verknüpfungen sämtliche anderen Vergleichsoperatoren herleiten, vorausgesetzt der Operator erzeugt eine strenge Totalordnung.

faszinierend
aber ja, logisch. wär ich nicht so schnell drauf gekommen.

Danke

Aus einem beschränkten Satz Bitoperationen andere Bitoperationen zu bauen ist recht Gang und Gebe in der THeorie.