Rückgabe von rValue-Referenzen in virtuellen Funktionen

XSpille

Gut, dass ich nachgefragt habe

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

Nexus

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...

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.

314159265358979

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

brotbernd

314159265358979 schrieb:

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.

Nexus

brotbernd schrieb:

Was ist das jetzt für eine Weisheit?

Es ist mehr eine Konvention.

Wichtiger ist eigentlich, dass operator=, wenn man sich nicht sehr dämlich anstellt, keine Referenz auf ein funktionslokales Objekt zurückgibt.

Nexus

Das stimmt natürlich. Ich merke gerade, dass ich wahrscheinlich den Post von Pi falsch interpretiert habe...

pumuckl

Um das mal etwas zu verdeutlichen, was hier geschrieben wurde: man kann nicht jedes Objekt "moven" bzw. nicht jede Klasse movable machen. Das hat nur Sinn, wenn eine Klasse Ressourcen belegt, die sie problemlos weiterschieben kann. Beispielsweise std::vector: Eine mögliche implementierung von vector hat intern
- ein size_t für die Anzahl der belegten Elemente (size())
- ein size_t für die Größe des Allokierten Speichers (capacity())
- einen Allokator
- eine Pointer auf den Speicherbereich, der dem vector gehört

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.

Eisflamme

Hi,

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...

Nexus

Eisflamme schrieb:

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.

pumuckl

Nexus schrieb:

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

Eisflamme

Okay, alles klar. MSVC unterstützt moveable Container noch nicht, richtig? Sind die Move-Container schon im aktuellen Draft? Ich schätze, ja.

Nexus

Eisflamme schrieb:

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.

hustbaer

Eisflamme schrieb:

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.

Eisflamme

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.

XSpille

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

#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;
}

Nexus

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.

XSpille

Nexus schrieb:

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....

krümelkacker

XSpille schrieb:

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.

hustbaer

XSpille schrieb:

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?