Rückgabe von rValue-Referenzen in virtuellen Funktionen

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?

XSpille

hustbaer schrieb:

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

pumuckl

XSpille schrieb:

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.

krümelkacker

Noch ein Zusatz. Das "Umkippen der Eimerinhalte" ist Sache des Klassendesigners. Wie/Was da genau passiert, wird im Move-Ctor definiert. Da steckt keine besondere Compiler-Magie hinter.