spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Das Objekt wird kopiert.

Nein, zumindest wenn es sich um einen c++11 => Compiler handelt findet hier Move Semantik Anwendung (Return Value Optimization (RVO)). (Move Semantics)

Klar wird das wegoptimiert. Aber vom Verständnis her.

Das ist auch nicht anders als "return 5;" oder "return true;". Oder "return my_string;".

Das Objekt wird wahrscheinlich nicht kopiert, es wird verschoben und ändert seinen Besitzer. Bei einer Kopie wird der Kopierkonstruktor aufgerufen. Dass wird hier nicht der Fall sein. Movesemantik ist keine Compileroptimierung sondern ein Teil der Sprache, sie ist nicht unsichtbar.

Understanding C++11 move semantics

Kopieren wird ja oft als so böse dargestellt, und ist auch recht ungünstig bei großen Objekten. Wenn man jetzt denkt hier würde Kopiert, so ist man sicher versucht ein nicht mehr vorhandenes Problem zu Optimieren/Lösen. Dies führt unnötiger weise zu unschönem Code. Sollte man jedoch erwarten, dass ein Kopierkonstruktor aufgerufen wird, so führt es sogar zu unerwartetem Verhalten.

Die einzelnen Member dieses einfachen Structs werden am Ende selbst bei einem Move-Constructor kopiert. Anders lassen sich primitive Typen gar nicht transferieren. Und damit wird effektiv der Vektor (es handelt sich hier nicht um einen std::vector!) komplett kopiert. Das ganze Theater ist für Julién vermutlich auch komplett irrelevant. Wichtig ist, dass es geht.
Mich würde aber wundern, wenn hier ein Move stattfinden würde, solange es weder der Vektor, noch die Funktion implementiert. Blöder weise lässt sich ideone sich nicht überreden den Konstruktor nicht komplett zu inlinen und somit wird weder move, noch copy constructor aufgerufen.

Also, angeommen, du hast sowas hier:


Was semantisch passiert, ist ungefähr folgendes:
- Die Ausdrücke in den Parametern werden ausgewertet. Bei der 5 ist man schon fertig, bei dem 18-4 führt man erst die Rechnung durch, taucht eine Variable auf, wird deren Inhalt geladen.
- Nachdem alle Werte feststehen, werden sie in den Parameterspeicher für die Funktion kopiert.
- Die Funktion kann auf diesen Speicher zugreifen und mit den Werten tun, was sie will.
- Die Funktion errechnet ein Ergebnis. Die Return-Anweisung kopiert das Ergebnis in einen Ergebnis-Speicherplatz.
- Alle Speicherbereiche die die Funktion verwendet hat, werden freigegeben - mit Ausnahme des Ergebnis-Speicherplatzes.
- Der Funktionsaufruf ist beendet und der Aufrufer der Funktion kann auf den Ergebnis-Speicherplatz zugreifen.

Wenn man das genau so machen würde, würde man oft Werte hin und her kopieren, was unnötig langsam ist. Deshalb kann der Compiler optimierten Code generieren, was einfach bedeutet, dass der Code etwas anderes tut, aber immer das selbe Ergebnis dabei produziert. Es gibt dabei noch ein paar Regeln, was auf jeden Fall immer passieren muss, aber trotzdem hat der Compiler noch viele Freiheiten. Es ist zum Beispiel möglich, dass das Objekt, was am Ende zurückgegeben wird, überhaupt nicht im Speicher der Funktion erstellt wird, sondern direkt im Speicher des Aufrufes, so dass beim zurückkehren überhaupt nichts kopiert oder verschoben werden muss. Man will natürlich ein wenig darauf achten, dass man den Code so schreibt, dass der Compiler gute Möglichkeiten zum optimieren findet, aber im Grunde genommen, muss man sich keine Gedanken darüber machen, wie der Code genau funktioniert, so lange man weiß, welche Auswirkungen er genau hat.