?
Dass ein Move-Konstruktor in allen Fällen schneller sein wird als ein Aufruf von rand(), wage ich mal zu bezweifeln, und der Zugriff auf eine deque im Vergleich zu vector ist nicht dermaßen teuer, dass im Falle eines mittelmäßig komplexen Kopier- bzw. Move-Konstruktors davon auszugehen wäre, dass der Zeitnachteil auf jeden Fall wieder herausgeholt werde. Auch werden die Kosten der Umlegung durch Move-Konstruktoren nicht eliminiert, sondern allenfalls gesenkt. Hat man einen teuren Kopierkonstruktor und einen etwas weniger teuren Move-Konstruktor, bleibt std::vector trotzdem auf den Kosten des Move-Konstruktors sitzen. Wie sich all das in der Praxis auswirken wird, kann ich zumindest heute noch nicht sagen.
Ich halte die Aussage "man sollte eigentlich immer zuerst vector nehmen und nur dann auf list oder deque wechseln, wenn diese erwiesenermaßen (Messung) schneller sind" nicht für zielführend. Seine Containerwahl sollte man nach Sachlage entscheiden; Kernfragen wie diese quasi als Dekoration zu betrachten, ist aus meiner Sicht unsinnig.
Noch etwas zu "premature optimization is the root of all evil": Das ist ein Knuth-Zitat aus einem Artikel von 1974, betitelt mit "Structured Programming with go to Statements" (Seite 8, rechte Spalte). Lasst den Titel mal einen Moment sacken. Mit Kontext liest sich die Stelle wie folgt:
Donald E. Knuth schrieb:
There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.
Wie gesagt: Es geht in diesem Artikel um die Benutzung von goto aus Performancegründen. Die Aussage hier ist: Optimierung, die die Handhabung des Codes erschwert, d.h. ihn unübersichtlicher macht, sollte nur dort passieren, wo sie tatsächlich etwas bringt. Auch denkt Knuth generell an sehr viel kleinere Optimierungen - lest euch den Artikel mal durch. Dass Knuth die Auswahl einer Containment-Strategie unter "Kleinkram, um den man sich keine Sorgen machen sollte" eingeordnet hätte, ist nicht plausibel. Mit Sicherheit hat er nicht sagen wollen, dass man sich beim Entwurf seines Programms keine Gedanken um Performance machen sollte.
Und natürlich ist im Zeitalter optimierender Compiler vieles dessen, was Knuth in diesem Artikel schreibt, inzwischen eh hinfällig.
