vector vs. eingebautes array
-
Optimizer boost::array bringt doch kaum Vorteile. Noch nicht mal ein Range-Check im operator[]. boost::array hat nur Vorteile wenn man Arrays zusammen mit anderen STL Sachen benutzen will.
-
Kaum Vorteile??
- Iteratoren
- Die Möglichkeit, nen Indexcheck selber einzubauen
- kann man schöner als Referenz übergeben
- kannst size abfragen.Und keine Nachteile.
-
Und keine Nachteile.
Doch. Abhängigkeit von Boost.
-
Nimmst du Quelltext, machen du strg + a, c, v und haben keine Abhängigkeit von boost.
-
Manche Leute denken echt zu kompliziert.
-
finix schrieb:
Ben04 schrieb:
finix schrieb:
Ingo schrieb:
aber ein vector hat riesigen Overhead.
Ja? Das hört sich interessant an. Wärest du so nett deine Messungen mal zu posten?
Was gibt es da zu messen? Der vector hat mehr Speicher reserviert als du brauchst => Speicherverschwendung.
Ja? Wird ja ständig interessanter. Würde trotzdem fast vermuten dass du mit einem Array IMMER den maximal benötigten Speicher reserviert hast. Mit dem vector nicht. Und da der maximal benötigte Speicher bekannt ist wirst du auch mit dem vector nicht mehr Speicher reserviert haben als du brauchst.
vector fordert IMMER mehr Speicher an denn der vector gross ist um zu verhindern, dass das Array neu angelegt werden muss wenn man nur ein Element am Ende anhängt. Ein C-array hingegen ist immer genau so groß wie man gefordert hat
-
Dann rüste mal endlich deinen Hauptspeicher von 640 KByte auf auf ein paar MByte auf. Ist heute nämlich ganz preiswert.
Was verbraucht denn vector so? Es reserviert ja nicht 1 MByte an, sondern je nach Implementierung unterschiedlich. vector von VC++7.1 reserviert zu Anfang garnichts. Wenn ich vier push_back() mache, hat er nur 4 (vier!) Felder reserviert. Mache ich ein reserve(100) hat er tatsächlich 100 Felder belegt. Also genau das, was ich auch mit einem C-Array machen würde. Könnt ihr mit capacity() abfragen.
Aber mir egal... macht doch was ihr wollt.
-
Artchi schrieb:
Was verbraucht denn vector so?
Man spricht von etwa faktor 2 bei alten stls und bei 1,5 bei neuen.
dh, wenn dein vector 100 elemente beinhaltet, hat er einen worstcase verbrauch von sizeof(element)*200das problem sind aber die dynamischen speicher anforderungen, die manchmal einfach unnoetig sind.
Wenn ich vier push_back() mache, hat er nur 4 (vier!) Felder reserviert.
Dann schmeiss diese implementierung weg. so ists ja viel zu lahm.
es sei denn du hast zufaellig mit 4 die kapazitaet ideal ausgelastet, dann teste mal mit 5 elementen.aber ich glaube ganz ehrlich, dass du die problematik hier nicht verstehst. niemand sagt dass vector schlecht ist, aber es ist bloedsinn vector zu verwenden wenn boost::array den job besser machen wuerde.
-
Ben04 schrieb:
finix schrieb:
Ben04 schrieb:
finix schrieb:
Ingo schrieb:
aber ein vector hat riesigen Overhead.
Ja? Das hört sich interessant an. Wärest du so nett deine Messungen mal zu posten?
Was gibt es da zu messen? Der vector hat mehr Speicher reserviert als du brauchst => Speicherverschwendung.
Ja? Wird ja ständig interessanter. Würde trotzdem fast vermuten dass du mit einem Array IMMER den maximal benötigten Speicher reserviert hast. Mit dem vector nicht. Und da der maximal benötigte Speicher bekannt ist wirst du auch mit dem vector nicht mehr Speicher reserviert haben als du brauchst.
vector fordert IMMER mehr Speicher an denn der vector gross ist um zu verhindern, dass das Array neu angelegt werden muss wenn man nur ein Element am Ende anhängt. Ein C-array hingegen ist immer genau so groß wie man gefordert hat
Oh, ich verstehe. Du legst einen vector mit einer Kapazität von 24 Elementen an und der vector reserviert heimlich noch mehr Speicher, hm? Willst du mich eigentlich vera****** oder weisst du es einfach nicht besser?
Ich will ja nicht dogmatisch behaupten das man IMMER einen vector nehmen sollte - wenn die Anforderung z.B. konstant bei 24 liegt ist ein array völlig OK - aber meistens ist das ganz einfach der Fall.
-
finix schrieb:
Ben04 schrieb:
finix schrieb:
Ben04 schrieb:
finix schrieb:
Ingo schrieb:
aber ein vector hat riesigen Overhead.
Ja? Das hört sich interessant an. Wärest du so nett deine Messungen mal zu posten?
Was gibt es da zu messen? Der vector hat mehr Speicher reserviert als du brauchst => Speicherverschwendung.
Ja? Wird ja ständig interessanter. Würde trotzdem fast vermuten dass du mit einem Array IMMER den maximal benötigten Speicher reserviert hast. Mit dem vector nicht. Und da der maximal benötigte Speicher bekannt ist wirst du auch mit dem vector nicht mehr Speicher reserviert haben als du brauchst.
vector fordert IMMER mehr Speicher an denn der vector gross ist um zu verhindern, dass das Array neu angelegt werden muss wenn man nur ein Element am Ende anhängt. Ein C-array hingegen ist immer genau so groß wie man gefordert hat
Oh, ich verstehe. Du legst einen vector mit einer Kapazität von 24 Elementen an und der vector reserviert heimlich noch mehr Speicher, hm? Willst du mich eigentlich vera****** oder weisst du es einfach nicht besser?
23.2.4
A vector is a kind of sequence that supports random access iterators. In addition, it supports (amortized) constant time insert and erase operations at the end;.
Wenn du es schaffst eine Implementirung zu schreiben die (in den meisten Fällen) konstant schnell am Ende anfügen kann und dann noch random access Iterators zur Verfügung stellt (verkettete Listen scheiden aus) und nicht mehr Speicher verbraucht als von den Elementen verbraucht wird (verkettete Listen und Bäume scheiden aus) dann Hut ab.
aber ich glaube ganz ehrlich, dass du die problematik hier nicht verstehst. niemand sagt dass vector schlecht ist, aber es ist bloedsinn vector zu verwenden wenn boost::array den job besser machen wuerde.
Genau, vector ist ein Array das dafür gebaut ist seine Größe zu verändern. Fals die Größe bekannt ist dann gibt es besseres.
Hier muss allerdings gesagt werden, dass es gibt Situation in denen boost::scoped_array boost::array vorzuziehen ist. boost::array legt die Daten in der Klasse ab, also auf dem Stack. Dies kann bei großen Arrays schonmal zu einem Stackoverflow führen. Meiner Meinung fehlt noch eine Spezialisirung für sizeof(T)*N>256.
-
Ben04 schrieb:
23.2.4
A vector is a kind of sequence that supports random access iterators. In addition, it supports (amortized) constant time insert and erase operations at the end;.
Wenn du es schaffst eine Implementirung zu schreiben die (in den meisten Fällen) konstant schnell am Ende anfügen kann und dann noch random access Iterators zur Verfügung stellt (verkettete Listen scheiden aus) und nicht mehr Speicher verbraucht als von den Elementen verbraucht wird (verkettete Listen und Bäume scheiden aus) dann Hut ab.
Kleiner Tip: schlag mal dict.leo.org auf und schau nach was amortized heißen könnte. Darüber hinaus stell dir folgende Situation vor: du hast einen vector, Kapazität 24 Elemente, Inhalt 23 Elemente. Du fügst ein Element am Ende an. Was passiert?
Ben04 schrieb:
aber ich glaube ganz ehrlich, dass du die problematik hier nicht verstehst. niemand sagt dass vector schlecht ist, aber es ist bloedsinn vector zu verwenden wenn boost::array den job besser machen wuerde.
Genau, vector ist ein Array das dafür gebaut ist seine Größe zu verändern. Fals die Größe bekannt ist dann gibt es besseres.
Genau. Das ist ja die Ausgangssituation, die Größe ist nicht bekannt, und sie verändert sich. Du hast lediglich eine Obergrenze, und da diese bekannt ist kommt man um die angesprochene Speicherproblematik herum. Was soll daran so schwer zu kapieren sein?
-
du hast einen vector, Kapazität 24 Elemente, Inhalt 23 Elemente
Kleine Frage : Wenn du eine Kapazität von 24 Elementen hast und weis, dass du nie mehr als 23 Elemente brauchen wirst, wird dann Speichrer verschwendet? Na?
Was soll daran so schwer zu kapieren sein?
Gute Frage, nur sehe ich nicht wen du damit ansprechen willst. Fals du mich meinst dann ließ doch noch einmal was ich geschrieben habe.
-
Ben04 schrieb:
du hast einen vector, Kapazität 24 Elemente, Inhalt 23 Elemente
Kleine Frage : Wenn du eine Kapazität von 24 Elementen hast und weis, dass du nie mehr als 23 Elemente brauchen wirst, wird dann Speichrer verschwendet? Na?
wenn du weisst, dass du nur 23 elemente brauchst, aber 24 reservierst, ist das nicht deine eigene dummheit? Na?
-
ist der Geschwindgkeits und Speicherverlust überhaupt bemerkbar? Wenn ja ab dem wievielten Element?
und kann ich an einen vector auch die zeiger von Klassen ranhängen?Achja, was den Stack angeht... werden die Elemente nun auf den Stack gelegt? Das wär nämlich schlecht (bei vielen Elementen). Irgendwie ist das so in der Diskusion untergegangen.
-
Chris++ schrieb:
ist der Geschwindgkeits und Speicherverlust überhaupt bemerkbar? Wenn ja ab dem wievielten Element?
Kommt auf die Situation und die Implementierung von vector an.
Chris++ schrieb:
und kann ich an einen vector auch die zeiger von Klassen ranhängen?
Warum nicht? std::vector<MeineKlasse*>
Chris++ schrieb:
Achja, was den Stack angeht... werden die Elemente nun auf den Stack gelegt?
Beim vector? Nein.
-
Chris++ schrieb:
ist der Geschwindgkeits und Speicherverlust überhaupt bemerkbar? Wenn ja ab dem wievielten Element?
Ich habe schon weiter oben gesagt: vector allokiert idR mit Faktor 2 bzw. modernen mit Fakto 1.5 einige behaupten auch 1.3 soll ideal sein...
dh, wenn du 100 elemente hast und neu allokieren musst, hast du speicher von 130 bis 200 elementen belegt.
jetzt rechne dass auch 10000 elemente um...
da kann eine schlechte allokations strategie sehr schlimm werden. denn bei vector hängt alles nur von der allokierung ab.Aber was ihr dauernd übergeht sind die kosten für die allokierung. die sind nicht groß, aber gegenüber einem array auf dem stack doch merkbar.
-
Shade Of Mine schrieb:
Aber was ihr dauernd übergeht sind die kosten für die allokierung. die sind nicht groß, aber gegenüber einem array auf dem stack doch merkbar.
In wie fern, positiv (geht schneller) oder negativ (langsamer). Ich würd mit meinem jetztigen Wissen ja auf negativ tippen da das Array ja jedesmal größer erstellt wird und die alten Daten erst rüberkopiert werden müssen.
Was die speicherallokierung angeht (um sicher zu gehen): es wird erst wieder neuer Speicher allokiert wenn der vorhandene aufgebraucht ist?
-
Chris++ schrieb:
In wie fern, positiv (geht schneller) oder negativ (langsamer).
langsamer.
Chris++ schrieb:
Was die speicherallokierung angeht (um sicher zu gehen): es wird erst wieder neuer Speicher allokiert wenn der vorhandene aufgebraucht ist?
Genau. Und dabei etwas mehr als du für die aktuelle Operation brauchst, um nicht ständig umkopieren zu müssen.
Ben04 schrieb:
du hast einen vector, Kapazität 24 Elemente, Inhalt 23 Elemente
Kleine Frage : Wenn du eine Kapazität von 24 Elementen hast und weis, dass du nie mehr als 23 Elemente brauchen wirst, wird dann Speichrer verschwendet? Na?
Wenn du schon nicht antworten willst dann lern zumindest lesen.
-
Also ich habe hier ein halbes Gigabyte an Speicher. Ob jetzt Speicher für 24 oder 48 Objekte angelegt wird, interssiert mich also erst, wen ein einzelnes Objekt verdammt groß sind.
Das ändert natürlich nichts daran, das boost::array hier am sinnvollsten erscheint.
-
finix schrieb:
Ben04 schrieb:
du hast einen vector, Kapazität 24 Elemente, Inhalt 23 Elemente
Kleine Frage : Wenn du eine Kapazität von 24 Elementen hast und weis, dass du nie mehr als 23 Elemente brauchen wirst, wird dann Speichrer verschwendet? Na?
Wenn du schon nicht antworten willst dann lern zumindest lesen.
Alles relevant wurde bereits gesagt. Und wenn du nicht siehst, dass man mehr Speicher holen muss als angefragt um ein Anfügen am Ende ohne Neuanlegung des Buffers zu realisiren, dann kann ich dir auch nicht helfen.
wenn du weisst, dass du nur 23 elemente brauchst, aber 24 reservierst, ist das nicht deine eigene dummheit? Na?
Die Implementirung kann frei wählen wie viel Speicher sie holt. Ich kann nur per reserve Tips geben.