spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Mach doch eine Funktion, die dein Element dem Vektor hinzufuegt. Die kannst du dann beliebig optimieren ohne das der Aufruf komplizierter zu schreiben waere.

Gib MyStruct einen entsprechenden Konstruktor und verwend v.emplace_back(...) oder zumindest v.push_back(MyStruct(...))
emplace_back() konstruiert das Objekt direkt im vector und die push_back() Variante mit dem temporären Objekt als Parameter sollte dem Compiler zumindest theoretisch erlauben, unnötige Kopien auszulassen und das Objekt ebenfalls direkt im vector zu konstruieren. Alle einigermaßen aktuellen Compiler (selbst VS 2008 ) machen von copy elision Gebrauch; wie gut das mit std::vector funktioniert, hängt natürlich von der jeweiligen Implementierung der Standardbibliothek ab, hab den konkreten Fall noch nie wirklich getestet...

Mit einem wirklich aktuellen Compiler, der initializer lists unterstützt, (VS 2013), kannst du auch sowas machen:

Ganz ehrlich? Wer macht sich Gedanken um solch premature optimizations?
Und ich mag mich irren, aber wäre es nicht cleverer den Vektor nur einmal zu resizen und dann darin den Elementen alle Werte zuzuweisen als das innerhalb der Schleife immer wieder zu machen?

Kommt drauf an, was im Defaultkonstruktor passiert.

Zitat von »BlueCobold«

Ganz ehrlich? Wer macht sich Gedanken um solch premature optimizations?

Zumindest ich hab das eigentlich so verstanden, dass es sich hier um eine Frage prinzipieller Natur handelt und seh eigentlich nicht wirklich, was das jetzt genau mit premature Optimization zu tun hätte. Passiert dir das nie, dass du dich bei gewissen grundlegenden Dingen, die du ständig machst, manchmal fragst, welche von all den verschiedenen Möglichkeiten das Gleiche zu tun nun eigentlich die effizienteste ist!? Mir geistern solche Fragen, selbst wenn ich gerade Python Skripte schreib, andauernd im Kopf herum...

Zitat von »BlueCobold«

Und ich mag mich irren, aber wäre es nicht cleverer den Vektor nur einmal zu resizen und dann darin den Elementen alle Werte zuzuweisen als das innerhalb der Schleife immer wieder zu machen?

Hängt am Ende natürlich, wie immer, stark von den konkreten Gegebenheiten ab, aber rein prinzipiell ist es selbstverständlich sinnvoller, den vector nur einmal zu resizen, wenn man die Größe vorher kennt. Wenn man die Größe vorher kennt und diese sich nie mehr ändern muss, könnte man evtl. überhaupt einfach nur einen unique_ptr verwenden statt einen vector, was möglicherweise nochmal ein wenig effizienter sein könnte. Aber das resize() in jeder Iteration ist vermutlich meistens schon so schnell, dass man kaum einen Unterschied merken wird, zumindest nicht im Vergleich zu push_back, da der vector seine Größe auf eine Art und Weise ändert, dass die amortisierte Laufzeit eines resize O(1) ist (ja, mit ausreichend kleinen Konstanten )...

Zur eingangs gezeigten optimierten Variante bzw. resize(): Prinzipiell haben diese beiden Varianten in Bezug auf Verhalten im Fehlerfall jeweils eine andere Bedeutung als die "unoptimierte" Variante. Ist der vector lokal und fliegt dieser somit im Fehlerfall weg, ist das egal. Übersteht der vector jedoch Fehler, hat er nach Auftreten eines solchen ggf. einen inkonsistenten Zustand: Seine Größe entspricht dann nicht mehr der Zahl gültiger/initialisierter Elemente. Eine sinnvolle und effiziente Variante wäre die folgende:



Man beachte move und die Klammerung, damit NewElement nach dem move nicht weiter verwendet wird. Für optimalen Code erfordert das Move Semantics für MyStruct - die laut C++11 automatisch generiert werden sollten - die Deppen bei MS bringen das aber frühestens zum VC++ 2013.5 Tech Preview raus.

Eine zweite Variante, in der du auch von Return Value Optimization profitieren kannst und in der das move andernfalls implizit durchgeführt wird, ist der Einsatz eines Lambdas:



Ich behaupte nicht, dass das hübsch ist. Aber da implizites Move von temporären Objekten meiner Meinung nach explizitem Move grundsätzlich vorzuziehen ist, wäre das wohl die empfohlene Variante. (Explizites Move erfordert immer eine Zusatzklammerung analog zur oben gezeigten oder das Wissen, dass das verschobene Objekt im Anschluss nicht länger gültig ist.)

Nebenbemerkung: Für maximale Effizienz sollte vector eigentlich eine allocate()-Methode analog zu reserve() anbieten, die ein vector_range-Objekt zurückgibt, welches push_back(), emplace_back() etc. anbietet. Dann fiele in der Schleife tatsächlich sämtlicher Maschinencode für potentielle Reallokation weg; ohne eine solche Funktionalität ist der Compiler gezwungen, auch bei vorangestelltem reserve() in der Schleife immer Code für Reallokation zu generieren, der dann tatsächlich niemals ausgeführt wird.

In keiner der beiden Varianten wird es dem Compiler aber möglich sein, das Objekt direkt im vector zu konstruieren, oder überseh ich was!?

Zitat von »dot«

In keiner der beiden Varianten wird es dem Compiler aber möglich sein, das Objekt direkt im vector zu konstruieren, oder überseh ich was!?

Nein, dazu bedarf es dann tatsächlich eines Konstruktors oder einer Initialisierungsliste (geht tatsächlich ab VC 2013!), jeweils mit emplace_back. In beiden Fällen ändert sich die Notation leider grundlegend, mit bedeutendem Informationsverlust.

Zitat von »CodingCat«

Zitat von »dot«

In keiner der beiden Varianten wird es dem Compiler aber möglich sein, das Objekt direkt im vector zu konstruieren, oder überseh ich was!?

Nein, dazu bedarf es dann tatsächlich eines Konstruktors oder einer Initialisierungsliste (geht tatsächlich ab VC 2013!), jeweils mit emplace_back. In beiden Fällen ändert sich die Notation leider grundlegend, mit bedeutendem Informationsverlust.

Dazu sollte man aber noch bemerken, dass sich bei ordentlicher Implementierung von Move Semantics der generierte Code einer Verschiebung des Objekts kaum von dem einer in-place Konstruktion mittels emplace_back-Forwarding unterscheiden sollte.