initializer_list

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

Columbo

decimad schrieb:

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

Und wie sieht dein Plan aus?

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

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

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?

Columbo

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.

Ja, dass ich per Template-Option anbiete, sie movebar zu machen, ist eigentlich inkonsequent. Aber irgendwie war ich da so im "flow" und es spart an einigen Stellen einige Zeilen Verwaltungs-Code, weil er so zentralisiert ist...
Eigentlich sind die Teile darauf ausgelegt, nicht bewegt zu werden. Der Move-"Hack" ist nur dafür da, dass ich nicht auf unique_ptr oder std::list ausweichen muss (was ich in der Vergangenheit dann auch tat, sogar in diesem Array-Fall, über den ich gerade nochmal drübergehe). Steht denn irgendwo geschrieben, dass Move effizient sein muss? Dachte es geht eher um Semantik, und die wird 1a eingehalten.

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.

Columbo

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.

no harm taken dude, let's carry on

zappenduster, eben kam mir die Idee, einfach ein uninitialized_array zu schreiben, aber die Jungs unter http://en.cppreference.com/w/cpp/types/aligned_storage hatten es schon fertig Wollte ich nur für andere mitleidende VC++-Benutzer erwähnt haben...

hustbaer

boost::optional ginge u.U. auch.
Nimmt einem ab aufzupassen dass man nicht vergisst was freizugeben. Kostet dafür natürlich zusätzlich ein paar Byte + ein paar Zyklen CPU Zeit.

Columbo

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

TNA

Arcoth schrieb:

@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.