Seh ich das richtig, dass es sich also nicht generell anbietet (gerade mit solchen Vererbungsketten) auf byvalue und move zu bauen?
Ich verstehe nicht, wie du den Schluss aus deinem Beispiel ziehst. Wenn die Vektoren groß sind, und Moves relativ zu Kopien nichts kosten, dann hast du damit die Laufzeit des Code-Schnipsels halbiert (falls genügend viele Funktionsargumente tatsächlich gemoved werden können!).
Ein Problem besteht darin, den Move beim Aufrufen des Setters auch konsequent zu nutzen. Wie willst du dem User sagen, dass er Moven sollte, wo möglich? Oder nutzt nur du das (und selbst dann wird es möglicherweise problematisch, sobald du die Funktion oder die Parameter veränderst).
Edit: Ich habe den Post nicht ganz zu ende gelesen...
Generell sind die ganzen Setter nicht performancekritisch, sodass ich der Konsistenz wegen zu const& überall tendieren würde.
Nun, um die Setter geht es nicht, sondern um den Datentyp der kopiert/gemoved werden soll. Sind es große Arrays o.ä.?
Das ist irgendwie unbefriedigend, da man beim Schreiben wissen muss, ob ein Typ einfach zu moven ist oder nicht, um den entsprechenden Setter anzubieten.
Dann wirst du dich auf eine Konvention festlegen müssen, die natürlich eine Const-Referenz sein wird. Das heißt, die Diskussion bringt hier nichts, da es sowieso Overkill bedeutet, Setter mit verschiedenen Übergabe-Methoden bereitzustellen, für Typen, die du nicht genau kennst (letzteres ist auch merkwürdig, warum weißt du nicht, ob die Typen schnell movebar sind?).
Man sollte so etwas auf keinen Fall für Objekte machen, bei denen der Laufzeitunterschied von Move und Kopie nicht so weit auseinanderliegt. Da kommt nämlich der Overhead von den "Zwischenobjekten" dazu, und das kostet moglicherweise mehr.
Aber das weißt du natürlich alles schon.
