also bisher hab ich rValue-Referenzen nur als Parameter verwendet.
Irgendwer hier im Forum hat - wenn ich mich richtig erinnere - mal gesagt,
dass man bei der Rückgabe von Objekten (normalerweise?) keine rValue-Referenzen
zurückgeben braucht, weil der Compiler - wenn möglich - implizit durch
den Move-Konstrukor statt des Copy-Konstruktors verwendet.

Wenn jetzt allerdings eine Funktion virtual ist, kann er das (glaube ich)
nicht mehr erkennen. Deswegen möchte ich halt explizit eine
rValue-Referenz zurückgeben.

Deswegen würde ich gerne wissen, ob das so zulässig ist:

#include <iostream>

class MoveObject{
public:
        MoveObject(){}
        MoveObject(MoveObject&& obj){
                std::cout << "move1" << std::endl;
        }

        MoveObject& operator=(MoveObject&& obj){
                std::cout << "move2" << std::endl;
                return *this;
        }

        MoveObject(const MoveObject& obj){
                std::cout << "copy1" << std::endl;
        }

        MoveObject& operator=(const MoveObject& obj){
                std::cout << "copy2" << std::endl;
                return *this;
        }

};

class A{
public:
        virtual MoveObject&& get(){
                return std::move(MoveObject());
        }
};

class B : public A{
public:
        virtual MoveObject&& get(){
                return std::move(obj);
        }
private:
        MoveObject obj;
};

void move_it(A& t){
        MoveObject o = t.get();
}

int main(int argc, char** arg){
        std::cout << "A:" << std::endl;
        A a;
        move_it(a);
        std::cout << "B:" << std::endl;
        B b;
        move_it(b);
        return 0;
}

Also eigentlich bin ich davon überzeugt, allerdings würde ich gerne
eine Bestätigung haben, bevor ich mir etwas falsch angewöhne.
Auf den ersten Blick scheint es ja auch zu funktionieren

A:
move1
B:
move1

(Ja, ich weiß, dass hier obj in B danach nicht mehr zu gebrauchen ist )
Ohne rValue-Referenz optimiert mein Compiler (scheinbar) die Kopie bei der Rückgabe
von A komplett raus:

A:
B:
copy1

Ich gehe mal davon aus, dass er move_it dann inlined.

Also nochmal abschließend die eigentliche Frage.
Ist das gültig:

virtual MoveObject&& get(){
                return std::move(/*myMoveObject*/);
        }

Gruß,
XSpille

EDIT: return type von operator=() korrigiert...

virtual MoveObject&& get(){
    return std::move(MoveObject());
  }

(dangling reference)

virtual MoveObject get(){
    return MoveObject();
  }

Wenn Du Dir unsicher bzgl Rvalue-Referenzen bist, dann bescgränke Dich darauf, sie nur für Move-Konstruktoren und Move-Zuweisungsoperatoren zu benutzten. Spar Dir auch unnötige std::move-Aufrufe. Wenn Du irgendwo ein std::move benutzt, wo es eigentlich nicht nötig ist, dann verhinderst Du damit copy/move-elision Optimierungen. Eine copy/move elision ist natürlich viel besser als eine move-konstruktion.

krümelkacker schrieb:

Rvalue-Referenzen sind REFERENZEN. Punkt. Ich kann mir beim besten Willen nicht erklären, warum so viele, die sich mit Rvalue-Referenzen beschäftigen, auf einmal Funktionen schreiben wollen, die Referenzen auf funktionslokale Objekte zurückgeben, die dann ungültig sind...

So hab ich es noch gar nicht gesehen...

Ehrlich gesagt war das && laut meiner (naiven) Annahme einfach nur die Erlaubnis
den Rückgabewert/Parameter zu 'zerstören'.

Immerhin gibt man ja auch ein MoveObject zurück, das auf dem Stack liegt.
Jetzt hätte man halt zusätzlich die Erlaubnis dieses zu manipulieren.
So war jedenfalls mein Gedanke.

Also theoretisch sollte das in der compilertechnischen Umsetzung doch
eigentlich keinen nennenswerten Unterschied machen.

Aber jetzt bin ich ja schlauer

Danke krümelkacker

Rvalue-Referenzen sind REFERENZEN. Punkt. Ich kann mir beim besten Willen nicht erklären, warum so viele, die sich mit Rvalue-Referenzen beschäftigen, auf einmal Funktionen schreiben wollen, die Referenzen auf funktionslokale Objekte zurückgeben, die dann ungültig sind...

Ich denke, das hängt damit zusammen, dass bisherige bekannte Konstrukte plötzlich eine neue Bedeutung bekommen. Bisher war klar, dass

MyClass Get();

eine Kopie erzeugt, im besten Fall noch mit (N)RVO wegoptimiert. Dass nun der gleiche Ausdruck ein implizites Move verursachen kann, wenn entsprechende Move-Konstruktoren definiert sind oder compilergeneriert werden, ist halt erst mal neu. Und da Move-Semantik zunächst immer mit RValue-Referenzen in Verbindung gebracht wird, scheint es naheliegend, dass man einen Move mit

MyClass&& Get();

kennzeichnet.

Außerdem gibt operator = einen Class& zurück.

Was ist das jetzt für eine Weisheit? MoveObject::operator=(const MoveObject&) gibt goarnix zurück. Der Operator sollte MoveObject& zurückgeben, wenn man das Schreiben von MoveObject a = b = c; erlauben möchte.

Was ist das jetzt für eine Weisheit?

Es ist mehr eine Konvention.

Der alte copy-Ctor musste folgende Schritte machen:
- Allokator kopieren
- neuen Speicher belegen (teuer!)
- Pointer auf den neuen Speicher setzen
- capacity entsprechend setzen
- alle Elemente rüberkopieren (möglicherweise auch teuer)
- size koperen

Der neue Move-ctor muss dagegen nur folgende Schritte machen:
- Allokator kopieren
- Pointer kopieren und Pointer des Originals auf 0 setzen
- capacity kopieren
- size kopieren

Daraus erkennt man, dass das Kopieren nicht komplett wegfällt (anders als einige wohl erwarten würden), es fällt nur der größte Teil weg.

Nehmen wir folgende Funktion und einen Aufruf:

vector f()
{
  vector vec; //(1)
  //...
  return vec; //(2)
}

//...
vector myvec = f(); //(3)

mit der alten copy-Semantik passiert folgendes:
an Stelle (1) wird ein vector konstruiert
an Stelle (2) wird ein neuer (temporärer) vector aus vec copy-konstruiert
an Stelle (3) wird myvec aus dem temporären Objekt copy-konstruiert

durch NRVO kann die Kopie an Stelle (2) wegoptimiert werden (meist nur im Releasemodus). vec wird dann quasi "außerhalb" der Funktion erstellt und darauf operiert, so dass er beim Verlassen der Funktion nicht erst herauskopiert werden muss. Es bleiben noch (1) und (3)

durch einen move-konstruktor in C++0x bindet das temporäre Objekt, das von f() zurückgegeben wird, an Stelle (3) an die RRef des move-ctor (weil temporäre Objekte eben rValues sind und deshalb an RRefs binden ). Außerdem weiß der Compiler, dass vec nach dem return zerstört wird und kann es in einen rvalue konvertieren, so dass er an Stelle (2) das temporäre Objekt aus vec move-konsturieren kann. Das allerdings nur, wenn NRVO nicht zieht und vec von vornherein außerhalb der Funktion konstruiert wird.

An der Stelle mit dem ist der Knackpunkt (und der Denkfehler, den der OP begangen hat): Du musst keine RRef zurückgeben, um move-Semantik zu ermöglichen.

Kann man jetzt also sagen, dass C++0x das Problem sämtlicher dicker "Moves" löst? Ich habe ja oft Folgendes:

ComplexObject createComplexObject()
{
ComplexObject z;
z.loadX("bla.txt");
z.loadY("blub.txt");
z.loadZ("balu.txt");
return z;
}

ComplexObject t = createComplexObject();

wenn die Ladeoperation zeitkritisch ist, ist es schade, wenn hier alles kopiert wird. Der größte Aufwand wird hier dann aber beseitigt, sodass das nix schadet?

Weiterführender Gedanke: Das ist jetzt super-spekulativ, dafür entschuldige ich mich im Voraus. Aber map braucht ja als value etwas copyables. Dürfte sich das durch die Move-Semantik nicht auch erübrigen, sodass es nur movable sein muss?

Ich muss mich da unbedingt Mal besser einlesen...

Kann man jetzt also sagen, dass C++0x das Problem sämtlicher dicker "Moves" löst?

Nicht sämtliche, aber viele. Die Klassen müssen movable sein. Und dann gibt es Fälle, die sich für Ressourcenklau nur bedingt eignen (z.B. statische Arrays).

Eisflamme schrieb:

Dürfte sich das durch die Move-Semantik nicht auch erübrigen, sodass es nur movable sein muss?

STL-Container werden movable, non-copyable Typen unterstützen. Allerdings ist mir nicht ganz klar, wie das Zusammenspiel mit kopierenden STL-Algorithmen konkret aussieht.

Allerdings ist mir nicht ganz klar, wie das Zusammenspiel mit kopierenden STL-Algorithmen konkret aussieht.

Kopierende Algorithmen werden natürlich copyable Elemente benötigen. Nur werden viele Algorithmen eben zu movenden Algorithmen

MSVC unterstützt moveable Container noch nicht, richtig?

Doch, die 2010er Version schon. Ich weiss allerdings nicht, wie weit die Unterstützung reicht, da ich bisher noch nicht gross von den neuen Features Gebrauch gemacht habe.

Okay, alles klar. MSVC unterstützt moveable Container noch nicht, richtig?

Äh, doch, schon. Die Container in der Stadnard-Library von Visual Studio 2010 unterstützen moveable Elemente und sind auch selbst movable.

Das einzige was noch nicht unterstützt wird sind die automatisch generierten Move-Konstruktoren und Move-Assigmnent-Operatoren.
Wenn du also Klassen hast die Container als Member haben, und willst dass diese Klassen von Move-Semantik profitieren, dann musst du selbst nen Move-Konstruktor und nen Move-Assignment-Operator definieren. (Im aktuellen Standard-Draft ist vorgesehen dass unter bestimmten Voraussetzungen automatisch welche generiert werden, aber das kann Visual Studio 2010 eben noch nicht)

BTW: std::map<Foo, MoveOnlyType> funktioniert mit Visual Studio 2010 problemlos.

Sind die Move-Container schon im aktuellen Draft? Ich schätze, ja.

Was für Move-Container? Die bestehenden Container vector, list, map, set etc. werden - dort wo es Sinn macht - angepasst, damit sie Moves für bessere Performance ausnutzen können. Bzw. damit man sie mit "move only" Typen verwenden kann, wo vorher kopierbare Typen nötig waren. Diese Anpassungen sind soweit ich weiss auch im aktuellen Draft schon enthalten - würde mich SEHR wundern wenn nicht.

Was für Move-Container? Die bestehenden Container vector, list, map, set etc. werden - dort wo es Sinn macht - angepasst, damit sie Moves für bessere Performance ausnutzen können

Das meinte ich - danke, das beantwortet alle meine Fragen.

#include <iostream>
#include <memory>

class MoveObject{};

class A{
public:
        virtual std::unique_ptr<MoveObject> get(){
                return std::unique_ptr<MoveObject>(new MoveObject());
        }
};

class B : public A{
public:
        B() : obj(new MoveObject()){
        }

        virtual std::unique_ptr<MoveObject> get(){
                return std::move(obj);
        }
private:
        std::unique_ptr<MoveObject> obj;
};

void move_it(A& t){
        std::unique_ptr<MoveObject> o(t.get());
}

int main(int argc, char** arg){
        A a;
        move_it(a);
        B b;
        move_it(b);
        return 0;
}

Ich werde dann wohl zukünftig, wenn es wirklich performance-technisch notwendig
ist, auf Heap-Objekte in einem unique_ptr zurückgreifen:

Wenn MoveObject movable ist, bringt das aber nichts. Durch die dynamische Allokation auf dem Freestore kann das Programm sogar langsamer werden.

XSpille schrieb:

Ich werde dann wohl zukünftig, wenn es wirklich performance-technisch notwendig
ist, auf Heap-Objekte in einem unique_ptr zurückgreifen:

Wenn MoveObject movable ist, bringt das aber nichts. Durch die dynamische Allokation auf dem Freestore kann das Programm sogar langsamer werden.

Aber sobald eine Funktion virtual ist, kann der Kompiler (meiner Meinung nach)
keine Aussage mehr darüber treffen, ob er das Objekt moven kann oder kopieren
muss...
EDIT: Zumindest, wenn es movebar und kopierbar ist.

Sehe ich das falsch?
Natürlich werde ich es nicht bei 'kleinen' Objekten verwenden.
Über den Overhead einer dynamischen Allokation bin ich mir bewußt....

Aber sobald eine Funktion virtual ist, kann der Kompiler (meiner Meinung nach)
keine Aussage mehr darüber treffen, ob er das Objekt moven kann oder kopieren
muss...

Das hat nichts mit virtuellen Funktionen zu tun. Ob man Objekte "moven" kann, hängt nur von der Klassendefinition ab, also, ob die Klasse Move-Ctor und Move-Assignment anbietet oder nicht.

XSpille schrieb:

Sehe ich das falsch?

Ja.

unique_ptr<> kann man auch nicht kopieren un trotzdem kannst Du das Ding von einer virtuellen Funktion zurückgeben.

Aber sobald eine Funktion virtual ist, kann der Kompiler (meiner Meinung nach)
keine Aussage mehr darüber treffen, ob er das Objekt moven kann oder kopieren
muss...
EDIT: Zumindest, wenn es movebar und kopierbar ist.

Müsste IMO egal sein.
Wichtig ist nur, dass der Return-Typ vollständig bekannt ist, und das ist er ja. Einerseits dort wo die Funktion definiert wird, und andrerseits auch dort wo sie aufgerufen wird.

Selbst mit Covariant-Returns kann man keinen Fall konstruieren der nicht ohne Covariant-Returns und ohne virtual functions auch möglich wäre.

Warum meinst du dass es einen Unterschied machen würde?

Warum meinst du dass es einen Unterschied machen würde?

Sorry an alle, die ich verwirrt habe

Knoten im Kopf...

Wer nicht weiter verwirrt werden möchte überspringt den Rest

Ich hatte mir eingebildet, dass bei dem Copy- bzw. Move-Konstruktor
in beiden Fällen, das Original-Objekt ankommt. Im zweiten Fall wird ja,
wie man auch an der Ausgabe, sieht eine Kopie vor der Rückgabe erstellt. Im Move-Konstruktor
würde (wenn es so wäre) die Member-Variable dann unbrauchbar gemacht, im Copy-Constructor nicht.
(Ich hab mir quasi eingebildet, man gibt ne Referenz zurück, was natürlich
im ersten Fall nicht geht und man ja auch anders in der Signatur angeben kann)
Naja... etwas verwirrt halt

Ich hatte mir eingebildet, dass bei dem Copy- bzw. Move-Konstruktor in beiden Fällen, das Original-Objekt ankommt.

Nein.

Kleine Analogie (die wie alle Analogien ihre Grenzen hat):
Siehs wie einen Eimer mit gefärbtem Wasser. Der Eimer ist das Objekt, das Wasser sind die Ressourcen - wenn du nur einen tropfenden kleinen Wasserhahn hast sinds teuere Ressourcen.
Ein Copy-Ctor würde den Eimer kopieren (neuen Eimer aus dem Schrank holen kostet nicht viel), den dann mit frischem Wasser volltröpfeln (das kostet Zeit!) und das dann genauso färben wie das Original. Der Originaleimer wird weggeworfen, vorher wird dessen gefärbtes Wasser weggekippt (d.h. die Ressourcen wieder freigegeben).

Ein Move-Ctor kopiert auch Eimer (nimmt also NICHT das Original, neuer Eimer kostet aber ja nicht viel) und kippt das Wasser aus dem alten Eimer in den neuen Eimer. Das darf er, weil der Originaleimer ein rValue ist, d.h. weil der eh gleich weggeworfen wird.

rValue-Referenzen sind also Referenzen, die extra für Wegwerfeimer gedacht sind

Nochmal der Klarheit halber: Es kommt nicht das Originalobjekt an - du hast ein neues Objekt, allerdings mit der selben Ressource wie im alten Objekt.

XSpille schrieb:

Im Move-Konstruktor würde (wenn es so wäre) die Member-Variable dann unbrauchbar gemacht, im Copy-Constructor nicht.

Im Grunde stimmt das. Nur geht es beim Moven nicht um x-beliebige Membervariablen sondern um Ressourcen, z.B. allokierten Speicher, Dateihandles, Verbindungen etc. (Ressourcenlose Dinge wie ints kann man nicht moven)
Im Move-Ctor wird die Ressource des Originalobjektes an das neue Objekt übergeben. Alles weitere (z.B. zusätzliche Daten, wie size und capacity beim vector-Beispiel oben) wird kopiert bzw. semantisch korrekt neu initialisiert.
Eine Nebenwirkung der ganzen Move-Geschichte ist, dass Destruktoren von movable Klassen den Fall berücksichtigen müssen, dass die Klasse die Ressource nicht mehr besitzt (Eimer leer), weil eben der Fall auftreten kann, dass sie per move-Ctor (oder move-Assignment) bereits an ein anderes Objekt der Klasse übergeben worden ist.

Also eine Art Idiom "Move-and-Swap"?