3. Rückgabe von rValue-Referenzen in virtuellen Funktionen

Rückgabe von rValue-Referenzen in virtuellen Funktionen

  • P

    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 😉

    0
  • E

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

    0
  • N

    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.

    0

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

    0
  • E

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

    0
  • X

    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;
}
    0
  • N

    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.

    0
  • X

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

    0
  • K

    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.

    0

  • 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?

    0
  • X

    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 👎

    0
  • P

    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.

    0
  • K

    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.

    0
  • N

    Lohnt es sich eigentlich, bei der Implementierung des Move-Konstruktors auf ein swap() zurückzugreifen, falls vorhanden? Man hätte möglicherweise ein paar unnötige Operationen, aber dafür ist die Implementierung einfach, semantisch korrekt und verwendet Code wieder.

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

    0

  • Wenn swap() einfach zu implementieren ist, und nichts unnötig rumkopiert, dann würde ich move() auf jeden Fall als swap() implementieren.

    Gründe die dagegen sprechen wären z.B.:
    * swap() muss mehr tun als move(). Möglich z.B. bei String-Klassen mit SSO (small string optimization) - wenn der Ziel-String "small" ist würde swap() dessen Inhalt in den "victim" String kopieren, was bei move() aber nicht nötig ist.
    * man möchte bestimmte Garantien für move() abgeben, wie es z.B. std::unique_ptr tut (victim ist nach move() garantiert NULL).

    Bei Klassen die keinen Default-Ctor haben kann man dadurch auch auf einen "untoten" Spezialzustand verzichten. Wobei sich natürlich die Frage stellt wie sinnvoll movable Types ohne Default-Ctor sind.

    p.S.: mit "move()" meine ich den Move-Assignment-Operator. Der Move-Ctor könnte dann analog erstmal ein "leeres" Objekt erstellen und dann swap() aufrufen. Nur für den Fall dass das nicht ganz klar war. Und das Eliminieren des "untoten" Zustandes funktioniert auch nur, wenn man keinen Move-Ctor sondern nur einen Move-Assignment-Operator implementiert. Zugegebenermassen reichlich fragwürdig 🙂

    0
Anmelden zum Antworten