moven ist teuer

Das ist in jedem Fall suboptimal.

Natürlich braucht man theoretisch keinen Move-Ctor

#include <iostream>

class foo
{
public:
	foo(int, int) { std::cout << "i,i-Ctor\n"; }
	foo(const foo&) = delete;
	foo(foo&&) = delete;
};

int main()
{
	foo arr[]{ {1, 2}, {3, 4} }; // < copy-list-initialization für die Arrayelemente
}

Allerdings kann das möglicherweise nicht ästhetisch sein.
Und initializer_list hat hier nichts verloren, dass hier ist in der Tat aggregate initialization (und das Aggregat ist natürlich das Array).

#include <vector>

struct gadget{
  gadget(int,int){}
  gadget(const gadget&) = delete;
  gadget(gadget&&) = delete;
};

int main(){
  gadget gs[] = {{1,2}, {3,4}, {4,5}};  // passt
  std::vector<gadget> vgs{{1,2}, {3,4}, {4,5}};  // autsch!
}

Aber Nathan, wieso verbreitest du Blödsinn? Natürlich braucht man keinen Move-Ctor

Nur nebenbei: Verbesserungsvorschläge kann man auch freundlich mitteilen. Du musst ausserdem nicht dauernd mit Worten wie "natürlich" so tun, als wäre jeder ein Idiot, der das nicht auf Anhieb weiss. Ansonsten musst du dich echt nicht wundern, warum du hier dauernd als Klugscheisser angesehen wirst.

Du musst ausserdem nicht dauernd mit Worten wie "natürlich" so tun, als wäre jeder ein Idiot, der das nicht auf Anhieb weiss.

Das tue ich auch nicht, denn 'natürlich' bedeutet hier, dass es einen direkten und einfachen Weg gibt, das zu erreichen, nicht, dass es jeder kennt.
Edit: Vielleicht sollte ich aufhören, 'natürlich' so zu verwenden... hehe

Das moven biete ich bei diesen Objekten überhaupt nur an, damit man sie in einem Container speichern kann und ist nur Tradeoff zwischen Faulheit und Effizienz. Es handelt sich um Endpunkte von Datenkanälen und die dürfen im Speicher nunmal nicht hin- und herwandern (es sei denn, man biegt alle Referenzen um, was in diesem Fall zweifellos genau keine sind, aber diese Referenzen zu speichern kostet *trommelwirbel* Speicher).

Zum Thema:

Das Array müsste in einer Initialization-List eines Konstruktors initialisiert werden und der Compiler hat gemäkelt, das für Arrays keine Initializer-List-Syntax-Initialisierung zulässig ist, die "="-Syntax kommt da ja nicht in Frage, oder?

der Compiler hat gemäkelt, das für Arrays keine Initializer-List-Syntax-Initialisierung zulässig ist

... Compiler ist VC++, oder?

Wie wäre es mit Design überdenken? Das sieht alles widersprüchlich aus.

VC++ stimmt, den Rest überlese ich jetzt einfach mal

Und wie sieht dein Plan aus?

std::vector<std::unique_ptr<>> ?

Wobei mich eines bezüglich Deines vorletzten Kommentars noch interessieren würde: Was genau sieht widersprüchlich aus, viel habe ich ja eigentlich gar nicht preisgegeben?

viel habe ich ja eigentlich gar nicht preisgegeben?

Nun, du willst Listen von nicht kopierbaren Elementen halten; Und das sie movebar sind, war eigentlich nicht vorgesehen. Also musstest du auf das Array verzichten... hmm.

Ich habe jetzt einfach 5 Member statt einem Feld von 5.

Wie oben gezeigt, dürftest du mit einem echten Array keine Schwierigkeiten haben, weil keine Kopien nötig sind.

Auf das Array verzichten muss ich leider, weil ich die Teile in einem Array nicht initialisiert bekomme, was ja offenbar ein VC++-Problem ist? Ansonsten wäre eigentlich alles in Butter.

weil ich die Teile in einem Array nicht initialisiert bekomme, was ja offenbar ein VC++-Problem ist?

Ganz vergessen, habe das glatt übersprungen. Dann bleibt dir wohl nichts anderes übrig. Vielleicht eine Union?

Steht denn irgendwo geschrieben, dass Move effizient sein muss?

Nein, vergiss das. Es ging nur darum, dass das Move gezwungenermaßen eingebaut wurde. Nicht weil das ein natürlicher Bestandteil der Klasse war.

@hustbaer:
boost::optional ist praktisch einfach ein unique_ptr . Wieso statt unique_ptr optional nehmen?

Ich denke, das ist nicht ganz richtig. Soweit ich weiß ist garantiert, dass das optionale Objekt innerhalb des boost::optional angelegt wird. Hier entfällt also die zusätzliche Indirektion und die dynamische Speicherallokation.