Wenn eine Funktion aufgerufen wird, muss die Funktion einen Wert zurückgeben. Dieser Wert benötigt Speicher zum Leben, aber der Rückgabewert muss die Funktion selbst übertreffen. Der ABI definiert, wie das alles funktioniert. Im Allgemeinen geschieht dies, indem der Aufrufer der Funktion ein Stück Speicher der Größe/Ausrichtung für den Rückgabewert bereitstellt.
Wenn also eine Funktion einen Wert berechnet und zurückgibt, muss er (theoretisch) diesen berechneten Wert in den Rückgabewertspeicher kopieren. Und wenn der Aufrufer es abruft, muss es (theoretisch) diesen Rückgabewertspeicher in ein anderes Stapelobjekt zur späteren Verwendung kopieren.
Nicht garantierte Kopie elision sagt, dass keine dieser Kopien notwendig ist. Auf der Seite der Rückgabefunktion darf der Compiler den Rückgabewertspeicher intern verwenden, wenn er diesen Wert generiert, sodass die Rückgabeanweisung nichts kopieren muss. Und auf der Empfangsseite, wenn der Speicher verwendet wird, um ein Stapelobjekt zu initialisieren, muss es nicht in diesen Speicher kopiert werden.
Garantierte Kopie elision sagt, dass, wenn die empfangende Seite ein Objekt desselben Typs initialisiert, der Empfänger nicht berücksichtigt, ob das Objekt einen Kopier/Verschiebe-Konstruktor hat. Daher wird der Code, der eine Funktion wie auto t = Func(); aufruft, ihn nicht als eine mögliche Kopieroperation in t behandeln. Der Compiler, der diesen Code verarbeitet, ruft Func mit dem Rückgabewertspeicher auf, der sich in dem Stapelspeicher für t befindet.
Und auf der Angerufenen Seite, wenn Sie einen prvalue direkt zurückgeben, dann ist es nicht notwendig, dass ein Copy/Move-Konstruktor existiert. Der Angerufene erstellt den Pr-Wert direkt im Rückgabewert-Speicher.
Hier ist die Sache: ABIs kümmern sich nicht darum. Alles, was ABI interessiert, ist Low-Level-Speicher. Das heißt, solange der Aufrufer Rückgabewertspeicher der geeigneten Größe und Ausrichtung weitergibt und der Aufgerufene diesen Speicher mit einem Objekt des geeigneten Typs initialisiert ... ist der ABI egal.
Wenn der Aufrufer diesen Rückgabewertspeicher für spätere Operationen verwenden möchte, ist das für den ABI in Ordnung. Wenn der Angerufene Daten direkt in den Rückgabewertspeicher initialisieren möchte, anstatt sie zu kopieren, wird der ABI dies nicht bemerken.
Der ABI definiert die Schnittstelle; Was Sie mit dieser Schnittstelle tun, bleibt Ihnen überlassen.
Als Beispiel betrachten Sie die Itanium ABI on return values. Es erlaubt Klassentypen, in Registern gespeichert zu werden, aber nur, wenn sie triviale Kopie-/Bewegungskonstruktoren haben. Andernfalls müssen sie unabhängig von ihrem Inhalt in dem Speicher aufgebaut werden, der von der aufrufenden Funktion bereitgestellt wird. Wenn die Klasse trivial kopierbar ist, können Sie den Unterschied zwischen Elision und Nicht-Elision nicht unterscheiden.
Die einzige Möglichkeit für ein ABI könnte ein Problem für diese Funktion sein, wenn die ABI willkürlich entschieden, wo der Rückgabewert (und vermutlich die Parameter) relativ zueinander gespeichert werden. Das heißt, der ABI zwingt den Aufrufer, das Objekt an einer bestimmten Position relativ zu den Parametern auf dem Stapel zu platzieren.
Könnte solch ein ABI existieren? Ich habe keine besonderen Kenntnisse zu sagen, dass es nicht möglich ist. Macht es? Ich bezweifle es eher, da solch ein ABI im Allgemeinen die Elision ziemlich schwierig machen würde.
Ich kann mir eine ABI vorstellen (wenn eine lächerliche), die durch diese Änderung gebrochen wäre. Wäre das ausreichend, oder suchen Sie nach tatsächlichen Instanzen eines ABI, die tatsächlich von einem tatsächlichen Nicht-Spielzeug-Compiler verwendet werden, der bricht? – Yakk
Wie können Sie etwas brechen, das nicht existiert? – user3104201
"* Ich denke an Dinge wie Initialisierungen, die Elide kopiert, wenn die Erstellung eines Objekts inline ausgeführt werden kann, aber nicht beim Überqueren von Compilierungseinheitsgrenzen. *" Ich kenne keine solchen Umstände, wo das möglich wäre. –