Angenommen, ich habe eine Klasse, in der der Kopierkonstruktor privat und nicht implementiert ist (um das Objekt nicht kopierbar zu machen)
%Vor%Jetzt schreibe ich in einer Member-Funktion derselben Klasse Code, der ein Objekt dieser Klasse zurückgibt:
%Vor%was ein Fall ist, wenn RVO eingreifen könnte.
RVO erfordert weiterhin, dass auf einen Kopierkonstruktor zugegriffen werden kann. Da der Aufruf des Kopierkonstruktors von derselben Memberfunktion aus aufgerufen wird, ist der Kopierkonstruktor zugänglich . So technisch ist RVO möglich, obwohl die Absicht darin bestand, den Kopierkonstruktor zu verbieten.
Ist RVO in solchen Fällen erlaubt?
Ihr Beispiel ist ziemlich interessant.
Dies ist die typische C ++ 03 Deklaration.
%Vor%Hier, wie erwähnt, kann RVO auftreten, obwohl wir semantisch vermeiden kopieren wollten.
In C ++ 03 besteht die Lösung darin, Folgendes zu delegieren:
%Vor% In C ++ 11 haben wir die Alternative, das Schlüsselwort delete zu verwenden:
Aber manchmal möchten wir das Kopieren verhindern, möchten aber Builder (wie im Muster) zulassen.
In diesem Fall funktioniert Ihr Beispiel , solange RVO in eintritt, was ein bisschen nervig ist, da es im Wesentlichen nicht standardisiert ist. Es sollte eine Definition des Kopierkonstruktors angegeben werden, die jedoch nicht verwendet werden soll.
In C ++ 11 wird dieser Anwendungsfall unterstützt, indem Kopiervorgänge gelöscht und Bewegungsvorgänge (auch privat) definiert werden.
Ja, RVO wäre in diesem Fall erlaubt - zumindest wenn der Aufrufer von Something() ein Klassenmitglied oder ein Freund war.
Ich denke, das ist ein Grund, warum die private Vererbung einer nicht kopierbaren Klasse besser ist als die manuelle Vererbung in jeder Klasse, die Sie nicht kopieren wollen. In diesem Fall gibt es keine zufällige Lücke.
Zum Beispiel mit boost::noncopyable :
Ein wichtiger Punkt kann die eigentliche Frage überschatten.
Was ist der Anwendungsfall einer solchen Funktion, wenn RVO erlaubt ist?
Diese Funktion kann auf 3 Arten aufgerufen werden, und 2 davon sind ein Compilerfehler:
%Vor%Man kann das zurückgegebene Objekt nicht effektiv benutzen, es ist also egal, ob das RVO erlaubt ist oder nicht.
Tags und Links c++ rvo copy-constructor