ZFX + Developia

Hallo Leute,

ich habe gerade eine kleine Helferklasse geschrieben, die grob so aussieht:
Ich kann diese Klasse jetzt einfach per Value rumreichen oder so aus dem Scope gehen lassen, weil der Compiler für mich ja Kopierkonstruktor, Zuweisungsoperator und Destruktor automatisch erstellt. Aber erstellt er für mich auch den Move Constructor und den Move Operator? Eigentlich müsste der ja auch so funktionieren wie die bisherigen automatisch generierten Funktionen: einfach elementweise übertragen.

Nebenbei: Wir brauchen mal eine angenehme deutsche Bezeichnung für die Move Semantics.

Bye, Thomas

Sie duerften automatisch generiert werden. Du kannst den Compiler aber auch mit einem MeinBeispiel(MeinBeispiel&&)=default (und dito fuer den Zuweisungsoperator) explizit darauf hinweisen - das waere dann aber wohl eher eine Erinnerung an dich, denn soweit ich weiss *muss* der Compiler die beiden Verschieber auch so generieren (wobei ich keine Ahnung habe, inwieweit VC den Standard aktuell umsetzt).

Gruss, Alex

Nach dem aktuellen Draft sollten sie automatisch generiert werden. Das Microsoft-VC++-Team hat jedoch bereits bekannt gegeben, dass VC++ dies erst mit der Annahme des neuen Standards implementieren wird. In VS 2010 wirst du deshalb definitiv immer selbst Hand anlegen müssen.

Dieses Feature ist bis heute heftig umstritten, weil immer wieder Fälle gefunden werden, in denen implizite Move-Konstruktoren und -Operatoren alten Code zerstören. Dennoch sieht der aktuelle Entwurf folgendes vor:

§12.8.10 hat geschrieben:If the definition of a class X does not explicitly declare a move constructor, one will be implicitly declared
as defaulted if and only if
— X does not have a user-declared copy constructor,
— X does not have a user-declared copy assignment operator,
— X does not have a user-declared move assignment operator,
— X does not have a user-declared destructor, and
— the move constructor would not be implicitly defined as deleted.
[ Note: When the move constructor is not implicitly declared or explicitly supplied, expressions that otherwise
would have invoked the move constructor may instead invoke a copy constructor. —end note ]

OMG

Die sind jetzt wirklich implizit?! D.h., die wiederholen jetzt genau die Handlung, die mich einmal im Monat implizit erzeugte Kopierk’toren verfluchen lässt?!

Un-glaub-lich. Warum tut man sowas? Faulheit? Weil die eine Zeile mit = default noch zu viel Text ist?! Weil es gut ist, sich viel vom Compiler abnehmen zu lassen, selbst, wenn der garnicht wissen kann, wie er es richtig tun soll?

Ich find's gut. Bzw. fände es gut, wenn Visual Studio 10 das implementieren würde. Nuja, muss man halt dran denken.

Nach meinem Wissen wird auch die "= default" oder "= delete" Notation noch nicht von VC10 unterstützt.

Impliziter Move-Ctor und -Assignment-Op sind afaik wieder aus dem Standard rausgenommen worden nachdem sich gezeigt hat dass es damit zu extremen Problemen mit vorhandenem Code kommt.

Okay, also ich habe mal ein wenig nachgeforscht und nach dem, was ich so gefunden habe, ist der Stand von November 2010, dass sich auf N3203 geeinigt wurde.

Das sagt u.a.: Hat eine Klasse einen user-defined D’tor oder Zuweisungsoperator, wird ein automatischer Kopierk’tor zwar noch erzeugt, ist aber deprecated (d.h., wird in einem der nächsten Standards rausfliegen). Umgekehrt gilt das auch für den automatischen Kopierzuweisungsoperator, falls ein user-defined Kopierk’tor deklariert wurde.

Verschiebek’toren werden zwar noch implizit erzeugt, allerdings nur, wenn

• die Klasse keinen user-defined Kopierk’tor hat;
• die Klasse keinen user-defined Kopierzuweisungsoperator hat;
• die Klasse keinen user-defined Verschiebezuweisungsoperator hat;
• die Klasse keinen user-defined D’tor hat; und
• er nicht als = delete erzeugt würde, was auch immer das heißen mag (ich schätze für den Fall, dass ein Attribut oder eine Superklasse keinen anbietet und er deshalb nicht erzeugt werden kann).

Damit fliegt fast alles raus, was nicht POD ist. Dasselbe gilt für den Move Assignment Operator. Damit wird bestmöglich vermieden, dass der automatische K’tor / Operator Invarianten verletzt indem er was anderes tut als das, was der Programmierer bspw. per Kopierk’tor und D’tor für gewöhnliche Kopien vorgibt.

Falls das tatsächlich der endgültige Stand ist bedeutet das, dass C++0x nicht nur nicht den Fehler mit den automatischen Kopierk’toren wiederholt, sondern ihn sogar noch nachträglich korrigiert indem diese deprecated markiert werden. In diesem Fall wäre ich erleichtert.

Falls hingegen jemand was noch Aktuelleres findert, bitte her damit.

Mein Zitat oben stammt aus dem Draft Feb 2011, wie zu sehen ist, ist der Text mit deiner Übersetzung identisch geblieben.

Bin ich heute blind oder habe was am Kurzzeitgedächtnis oder so? Ich hatte es echt nicht gelesen. ’Tschuldigung.

Krishty hat geschrieben:Bin ich heute blind oder habe was am Kurzzeitgedächtnis oder so? Ich hatte es echt nicht gelesen. ’Tschuldigung.

So war das aber gar nicht gemeint, sondern mehr als Antwort auf das: ;-)

Krishty hat geschrieben: Falls hingegen jemand was noch Aktuelleres findert, bitte her damit.

Den aktuellsten Draft April 2011 hingegen gibts laut Wikipedia leider (noch?) nicht öffentlich. N3242 (Feb11) ist somit der aktuellste einsehbare.