Rule of 0



  • Hab gestern einen Talk von Jason Turner geschaut und in dem spricht er unter anderem über die Rule of 0, also das Bestreben kein manual ressource management zu betreiben, da sonst die Definition eines Desturktors notwendig wird, was dann die Definition der anderen Special Member Funktions nach sich zieht (Rule of 5)

    Er meint dass bei einer Vererbungshierarchie mit einer Basisklasse wie der Folgenden

    class Base
    {
    public:
      virtual ~Base() = default;
    };
    

    die default definiton des Destructors bedeutet, dass man auch die anderen 4 Special member functions defaulten solle, da beispielsweise die Move funktionen sonst implizit deleted seien. Bei Subklassen wäre hingegen eine explizite Definition dieser Funktionen dann nicht mehr nötig, wenn diese kein eigenes Ressourcen Management machen. Ist das korrekt? Sehenämlich häufig Basisklassen, wo, wie oben, nur der Dtor defaultet ist. Löscht man dadurch dann nicht eben die move operatoren?



  • Siehe http://en.cppreference.com/w/cpp/language/move_constructor, Abschnitt "Implicitly-declared move constructor"



  • ja kenne ich, die Frage ist pb

    ~Foo() = default;

    ein user-declared dtor ist und wenn ja, wieso dann in vielen Beispielen mit Vererbung, die Basisklasse die Move funktionen nicht auch defaultet, da sie doch sonst deleted sind. Und ist der obige Syntan eine Deklaration oder eine Definition?


  • Mod

    Sewing schrieb:

    ja kenne ich, die Frage ist pb

    ~Foo() = default;

    ein user-declared dtor ist

    ist es.

    Sewing schrieb:

    und wenn ja, wieso dann in vielen Beispielen mit Vererbung, die Basisklasse die Move funktionen nicht auch defaultet, da sie doch sonst deleted sind.

    Wegen Faulheit, Unachtsamkeit oder weil typischerweise polymorphe Klassen recht wenig mit Movekonstruktoren anfangen können.

    Sewing schrieb:

    Und ist der obige Syntan eine Deklaration oder eine Definition?

    Beides.



  • camper schrieb:

    ... weil typischerweise polymorphe Klassen recht wenig mit Movekonstruktoren anfangen können.

    wieso?


  • Mod

    Sewing schrieb:

    camper schrieb:

    ... weil typischerweise polymorphe Klassen recht wenig mit Movekonstruktoren anfangen können.

    wieso?

    Um ein Objekt vernünftig moven zu können, müssen statischer und dynamischer Typ übereinstimmen - da bleibt kein Raum für Polymorphie. Das gilt zwar im Prinzip auch für Copyctors, dort bekommt man Polymorphie aber hin über den Umweg von clone-Funktionen. Was wäre das Move-Äquivalent zu clone?



  • mlone?

    ; )

    danke für die antwort.


Anmelden zum Antworten