Klasse erzeugen, die eine unbestimmte Anzahl an Objekten einer anderen Klasse enthält (Vektor)
-
Hallo Leutz,
sicherlich kein neues Problem. Ich habe eine Klasse für Linienobjekte erstellt. Ich benötige aber ebenfalls eine Klasse, die mehrere Linienobjekte beinhaltet. Die Anzahl der Linienobjekte ist a priori nicht bekannt.
Irgendwie komme ich mit der dynamischen Erzeugung, wie in einer main ala
int n = 20;
Line *Line_objekt = new Line[n];nicht hin.
-
schau dir mal std::vector<> an, falls die anzahl der Objekte während der Laufzeit konstant ist,
oder std::list<> falls nicht.Devil
-
schau dir mal std::vector<> an, falls die anzahl der Objekte während der Laufzeit konstant ist
-
Hallo,
er meint damit wahrscheinlich, dass das Einfügen beim Vector langsamer ist als bei einer List. Allerdings würde ich eher sagen, dass vor allem von der Art des Lesezugriffs abhängt, und das ist Vector natürlich schneller.
EDIT: Wenn die Anzahl der Objekte definitiv konstant ist, würde ich keinen Vector benutzen, sondern ein normales Array.
-
Die Anzahl der Objekte ist nicht konstant. Es wird so ablaufen, dass der Bearbeiter am Bildschirm eine bestimmte Anzahl an Linien auswählt und dann Berechnungen durchgeführt werden. Die Anzahl der ausgewählten Linien soll aber während des Programmablaufes immer veränderbar sein.
-
Dann würde ich in jedem Fall einen STL-Container verwenden. Welchen du nimmst
hängt von deinen konkreten Anforderungen ab. Zur Entscheidungsfindung kuckst du
am besten mal in eines der gängigen Tutorials/Bücher.
-
Solange die neuen Objekt immer nur ans Ende angefügt werden ist std::vector<> zu empfehlen. Mit konstant hat das nichts zu tun. Wäre es Konstant zur Laufzeit, würde die meisten wohl ein C-Array nehmen.
-
Artchi schrieb:
Solange die neuen Objekt immer nur ans Ende angefügt werden ist std::vector<> zu empfehlen.
Kommt wohl eher darauf an wie der (hauptsächliche) Zugriff aussieht wie CarstenJ gesagt hat. Wenn sowie so jedes mal über alle Linien iteriert wird empfiehlt sich imho eher eine std::list...
-
Artchi schrieb:
Solange die neuen Objekt immer nur ans Ende angefügt werden ist std::vector<> zu empfehlen. Mit konstant hat das nichts zu tun. Wäre es Konstant zur Laufzeit, würde die meisten wohl ein C-Array nehmen.
Das würde ich so nicht sagen...
Kommt auf die größe des Objektes an, welches du immer
wieder anhängst, denn der vector kopiert immer den ganzen Speicher
von allen objekten, wenn du push_back benutzt, und nicht vorallokiert hast.
Deswegen bei häufigem einfügen oder entfernen von Objekten -> std::list
sonst vector, wenn es wichtig ist schnellen zugriff darauf zu haben.Devil
-
finix schrieb:
Artchi schrieb:
Solange die neuen Objekt immer nur ans Ende angefügt werden ist std::vector<> zu empfehlen.
Kommt wohl eher darauf an wie der (hauptsächliche) Zugriff aussieht wie CarstenJ gesagt hat. Wenn sowie so jedes mal über alle Linien iteriert wird empfiehlt sich imho eher eine std::list...
Dies ist eine Vermutung. Wissen kann das nur der Thread-Ersteller und der
sollte sich daher in den einschlägigen Quellen informieren was für ihn am
günstigsten ist.
-
devil81 schrieb:
Das würde ich so nicht sagen...
Kommt auf die größe des Objektes an, welches du immer
wieder anhängst, denn der vector kopiert immer den ganzen Speicher
von allen objekten, wenn du push_back benutzt, und nicht vorallokiert hast.
Deswegen bei häufigem einfügen oder entfernen von Objekten -> std::list
sonst vector, wenn es wichtig ist schnellen zugriff darauf zu haben.Devil
Nicht wenn ich vorreserviere. Wenn ich z.B. weiß "OK, es sind so im Durchschnitt 100 Objekte", dann kann man das dem vector auch sagen. Der speichert nämlich zwei Werte: 1x den reservierten Array und 1x den tatsächlich belegten Array. Und wenn ich nur Pointer in den Vector packe, muß er "nur" die Pointer kopieren. Aber ich würde das vermeiden in dem ich immer für genug Reserve sorge. Die meisten vector-Implementierungen machen das auch von sich aus. Und wenn die das nächste Mal vergrößern müssen, weil die Reservierung nicht ausreicht, reservieren die wieder mehr. Oder glaubst du, der kopiert bei jedem neuen Element den ganze Vector in einen neuen?
Ist ja naiv. Es mag ja solche Implementierungen geben, aber so ist vector eigentlich nicht konzipiert.
-
Artchi schrieb:
devil81 schrieb:
Das würde ich so nicht sagen...
Kommt auf die größe des Objektes an, welches du immer
wieder anhängst, denn der vector kopiert immer den ganzen Speicher
von allen objekten, wenn du push_back benutzt, und nicht vorallokiert hast.
Deswegen bei häufigem einfügen oder entfernen von Objekten -> std::list
sonst vector, wenn es wichtig ist schnellen zugriff darauf zu haben.Devil
Nicht wenn ich vorreserviere. Wenn ich z.B. weiß "OK, es sind so im Durchschnitt 100 Objekte", dann kann man das dem vector auch sagen. Der speichert nämlich zwei Werte: 1x den reservierten Array und 1x den tatsächlich belegten Array. Und wenn ich nur Pointer in den Vector packe, muß er "nur" die Pointer kopieren. Aber ich würde das vermeiden in dem ich immer für genug Reserve sorge. Die meisten vector-Implementierungen machen das auch von sich aus. Und wenn die das nächste Mal vergrößern müssen, weil die Reservierung nicht ausreicht, reservieren die wieder mehr. Oder glaubst du, der kopiert bei jedem neuen Element den ganze Vector in einen neuen?
Ist ja naiv. Es mag ja solche Implementierungen geben, aber so ist vector eigentlich nicht konzipiert.Doch, so ist er konzipiert, wenn man nicht vorreserviert. Und das Kopieren bleibt
dir nicht erspart, wenn du dinge löschst.Devil
-
Chew-Z schrieb:
finix schrieb:
Artchi schrieb:
Solange die neuen Objekt immer nur ans Ende angefügt werden ist std::vector<> zu empfehlen.
Kommt wohl eher darauf an wie der (hauptsächliche) Zugriff aussieht wie CarstenJ gesagt hat. Wenn sowie so jedes mal über alle Linien iteriert wird empfiehlt sich imho eher eine std::list...
Dies ist eine Vermutung. Wissen kann das nur der Thread-Ersteller und der
sollte sich daher in den einschlägigen Quellen informieren was für ihn am
günstigsten ist.OK, im Namen der Lesbarkeit ersetze "Wenn" durch "Falls" oder ggf "Falls z.B.". Wenn/Falls das alles nichts hilft streich den zweiten Satz
-
devil81 schrieb:
Doch, so ist er konzipiert, wenn man nicht vorreserviert.
Growfaktor 1.5 bis 2.0 - viele implementierungen verdoppeln also ihren speicher pro neuallokierung.
das nenne ich schon 'vorreservieren'.