Virtuellen Destruktor mit virtuellen Mitgliedern, die in C++11

In diesen Folien über C++11/14 standard, auf Folie 15 der Autor schreibt, dass "viele klassische Codierung Regeln [sind] nicht mehr anwendbar," in C++11. Er schlägt vor, eine Liste von drei Beispielen, und ich Stimme zu, die Regel der Drei und das Speicher-management.

Jedoch seine zweite Beispiel ist die "Virtuellen Destruktor mit virtuellen Mitglieder" (nur, dass). Was bedeutet es? Ich weiß, man muss erklären, wie virtuelle Basisklasse destructor, um die richtige Destruktor, wenn wir so etwas wie

Base *b = new Derived;
...
delete b;

Dies ist gut erklärt hier: Wenn man virtuelle Destruktoren?

Aber es ist nutzlos, jetzt in C++11 zu erklären, Ihre virtuelle Destruktor, wenn Sie virtuelle Mitarbeiter?

  • Dies ist nur eine Vermutung, aber bei der Verwendung von smart-Pointer, können Sie ordnen die Dinge so, dass der richtige Destruktor aufgerufen wird, auch wenn die Basis-Destruktor nicht virtuell. Dies geschieht aus der box mit shared_ptr.
  • Die Aussagen zu der Wirkung, dass die in der Regel aus drei oder die Notwendigkeit für einen virtuellen Destruktor nicht mehr notwendig sind, sind schlicht falsch. Keine der neuen Funktionen haben sich etwas geändert in dieser Hinsicht.
  • Über die Regel der Drei, der Autor könnte auch bedeuten, dass es veraltet ist, da nun es ist die Regel der Vier/Fünf. Für die Regel der Null, ich glaube wirklich, dass es sinnvoll ist, aber unter der Bedingung, dass Ihre Klassen verwenden, die RAII-Prinzip für alle Ressourcen, die Sie besitzen.
  • Nicht wirklich. Die meisten Klassen brauchen nicht die zusätzliche Komplexität der Unterstützung bewegen. (Und Klasse, die Ressourcen verwendet, die muss freigegeben werden, richtig arbeiten benötigen in der Regel viel mehr als das, was die üblichen RAII-Klassen tun können.)
  • Sie fehlt der Punkt. Wenn alle Ihre nicht-triviale Mitglieder haben eine richtige Destruktor oder ein RAII-Typ mit einem geeigneten deleter (ob das gleich löscht den Speicher oder führt komplizierter cleanup), dann gibt es keine zusätzliche Komplexität zu unterstützen verschieben. Sie sagen einfach Foo(Foo&&) = default; und es Einfach Funktioniert™. Und weil alle Ihre Mitglieder sich selbst reinigen, können Sie auch Standard-Destruktor. Es erfordert einen anderen Ansatz zur Klasse design, aber das ist der Ansatz von Prof. Sommerlad befürwortet in diesen Folien. (Nicht sicher über die virtuelle bisschen aber ich werde ihn Fragen.)
  • die Antwort von PeterSom scheint mir perfekt...
  • Es ist in der Tat! Ich wurde gefragt, für details über diese gleitet, und eine Antwort bekommen, von dem Autor selbst. 🙂 Ich werde belohnen Sie seine Antwort mit der bounty und die beste Antwort, sobald die bounty fertig (morgen). Bezweifle ich, es wird besser beantworten...

InformationsquelleAutor Florian Richoux | 2014-04-02
  1. 36

    Als Autor der Seiten ich werde versuchen, das zu klären.

    Wenn Sie code schreiben, der explizit die Gewährung einer Derived Instanz mit new und zerstören es mit delete mit base class pointer ist, dann müssen Sie definieren eine virtual Destruktor, ansonsten Sie am Ende mit unvollständig Zerstörung der Derived Instanz. Allerdings empfehle ich zu verzichten new und delete vollständig und verwenden Sie ausschließlich shared_ptr für die Bezugnahme auf heap-allocated polymorphe Objekte, wie

    shared_ptr<Base> pb=make_shared<Derived>();

    Diese Weise wird der shared pointer verfolgt die original-Destruktor verwendet werden, auch wenn shared_ptr<Base> wird verwendet, um Sie zu vertreten. Einmal, das Letzte bezieht shared_ptr geht out of scope oder zurückgesetzt wird, ~Derived() aufgerufen werden und der Speicher freigegeben. Daher brauchen Sie nicht zu machen ~Base() virtuellen.

    unique_ptr<Base> und make_unique<Derived> nicht bieten dieses feature, weil Sie nicht die mechanik der shared_ptr mit Bezug auf die deleter, weil der einzige Zeiger ist viel einfacher und soll für den geringsten overhead und damit ist nicht die Speicherung der zusätzlichen Funktion Zeiger benötigt für die Streicher. Mit unique_ptr die deleter-Funktion ist Teil der Art und Weise ein uniqe_ptr mit einer deleter bezogen auf ~Derived wäre nicht kompatibel mit einer unique_ptr<Base> mit dem Standard-deleter, das wäre falsch, für die eine abgeleitete Instanz sowieso, wenn ~Base war nicht virtuell.

    Die einzelnen Vorschläge, die ich machen, sind dazu gedacht, um einfach zu sein zu Folgen und alle Folgen zusammen. Sie versuchen zu produzieren, einfacher code, indem alle Ressourcen-management erfolgen durch die Bibliothek-Komponenten und den vom compiler generierten code.

    Definition einer (virtuellen) Destruktor in einer Klasse, werden die es verbieten, dass ein compiler-zur Verfügung gestellt move-Konstruktor/Zuweisungsoperator und verbieten können auch einen compiler zur Verfügung gestellt copy-Konstruktor/Zuweisungsoperator in zukünftige Versionen von C++. Er hat sich einfach mit =default, aber sieht immer noch wie eine Menge boilerplate-code. Und das beste code ist der code, den Sie nicht schreiben müssen, denn es kann nicht falsch sein (ich weiß, es gibt noch Ausnahmen zu dieser Regel).

    Zusammenfassen "nicht definieren, eine (virtuelle) Destruktor" als eine Ergänzung zu meiner "Regel-der-Null":

    Immer, wenn Sie entwerfen eine polymorphe (OO) - Klasse Hierarchie in der modernen C++ und wollen/müssen auf allocate its-Instanzen auf dem heap, und der Zugang zu Ihnen durch ein base class pointer verwenden make_shared<Derived>() zu instanziieren Sie und shared_ptr<Base> um Sie ringsherum zu behalten. Dies ermöglicht Ihnen, halten die "Rule of Zero".

    Dies bedeutet nicht, Sie muss weisen polymorphe Objekte auf dem heap. Zum Beispiel, die Definition einer Funktion, die ein (Base&) als parameter, aufgerufen werden können mit einem lokalen Derived variable ohne Probleme und verhält sich polymorph, mit Bezug auf virtuelle member-Funktionen von Base.

    Meiner Meinung nach dynamischer OO-Polymorphismus ist stark überstrapaziert in vielen Systemen. Wir sollten nicht Programm wie Java, wenn, die wir verwenden, C++, es sei denn, wir haben ein problem, wo dynamischen Polymorphismus mit heap zugeordneten Objekten ist die richtige Lösung.

    • Ich Häufig umgestalten meinem Erbe-Strukturen, und manchmal am Ende mit einer anderen Klasse als ultimative Basisklasse, wie wird diese behandelt werden, im Fall von shared_ptr<Base> pb=make_shared<Abgeleitet>(); als Modell verwendet ?
    • Ich bin mir nicht sicher, ich verstehe Ihr Anliegen richtig. Wenn Base ist eine Basis-Klasse Derived meine Argumente sind noch gültig. Allerdings, wenn Base ist völlig unabhängig von Derived dann sollte das auch nicht kompilieren.
    • Okay, danke. Der compiler dann sagen Sie es mir.
    • Ich denke, dass NICHT die Definition der virtuellen Destruktor für eine Klasse, die verwendet werden soll, polymorph stellt eine große Belastung für den Benutzer der Klasse - Sie sind unbedingt erforderlich, um Sie zu halten mit shared_ptr. Aber shared_ptr ist sehr entmutigt und als überstrapaziert und sollte ersetzt werden durch unique_ptr, Wann immer möglich. So, glaube ich, nicht die Definition der virtuellen Destruktor führt zu viel schlimmeren Problemen, als die Tatsache zu akzeptieren, dass Sie zu markieren, kopieren und verschieben-Konstruktor und Zuweisungsoperator als =default. Ich denke, dass C++11 nichts verändert darüber, Wann und wie man virtuelle Destruktoren.
    • Dies scheint nicht, wie sehr gute Beratung - Sie sparen eine triviale Menge von (mentalen) Aufwand bei der Deklaration der Klasse, im Austausch für die Verhängung einer nicht-trivialen (geistige) overhead durch die Beschränkung der Kunde die Nutzung in einer eher unerwarteten Art und Weise. Sie sind auch Handel mit einem kleinen Aufwand eine virtual-lookup-einmal, wenn ein Objekt zerstört wird, ist vs... eine kleine virtual-lookup, wenn ein Objekt zerstört wird. Das scheint nicht allen, die hilfreich für mich.
    InformationsquelleAutor PeterSom
  2. 2

    Ich denke, dass dies zu tun ist mit der "rule of zero" erwähnt an anderer Stelle in der Präsentation.

    Wenn Sie nur die automatische member-Variablen (D. H. die Nutzung shared_ptr oder unique_ptr für Mitglieder, die sonst rohe Zeiger), dann brauchen Sie nicht zu schreiben, Ihre eigenen kopieren oder verschieben von Konstruktoren oder Operatoren -- der compiler-vorausgesetzt defaults optimal sein wird. Mit in-class-Initialisierung, die Sie nicht benötigen einen Standard-Konstruktor entweder. Und schließlich müssen Sie nicht schreiben Sie einen Destruktor an alle, virtuellen oder nicht.

    • Ja, aber laut Scott Meyers, bleibt es vorzuziehen, die explizit erklären, das kopieren/verschieben ctors, der copy/move-Zuweisungs-Operator und Destruktor als default (scottmeyers.blogspot.fr/2014/03/...). So ist nach dieser geänderten Regel von Null, Schätze ich, dass man immer noch erklären müssen das Basis-Destruktor werden virtuelle.
    • Es ist eine Art von albern, dass, wenn es eine virtuelle Mitglied irgendwo ist, dann wird UB nicht über einen virtuellen Destruktor; aber, wenn es keine virtuellen member, als es aufwendig ist, einen virtuellen Destruktor. Das ist fragil; gibt es einen Grund, warum destuctors sollte nicht "automatisch" virtuellen werden in einer Klasse, bekam schon eine vtable, und nicht-virtuellen in anderen?
    • Ich glaube, dass Scott Meyers ist zu viel kleben, um seine eigene Vergangenheit, wenn er über die "Rule of Zero". Ich bin versucht, die Dinge so einfach wie möglich. Die Festlegung der Regel-compiler-zur Verfügung gestellt spezielle member-Funktionen (richtig!) sollte ein feature-Links für die Bibliothek von Experten und nicht etwas, das passiert im regulären code, die meisten C++ - Programmierer erstellen.
    • McNabb: wenn Sie Folgen Sie meine Regeln, dann werden Sie nicht bekommen, UB, ohne einen virtuellen Destruktor und Sie würde nie kommen, um die situation zu schreiben, die einen virtuellen Destruktor erzeugen einen unnötigen overhead.
    • "Ihre Regeln" sein, um immer nur shared_ptr zu zeigen, um polymorphe Objekte? OK, zwar bin ich immer noch glücklicher, wenn die definition einer Klasse ist korrekt, in sich selbst, ohne sich auf die Benutzer, die in ein bestimmtes idiom. Diese Benutzer können manchmal so seltsame Sachen...
    • +1 mcnabb für die Erwähnung der Unterschied zwischen der Definition der Klasse und mit der Klasse. Es wäre schlechte form, eine Klasse zu definieren, die eingesetzt werden mussten, die mit einem bestimmten Typ ptr.

    InformationsquelleAutor Tristan Brindle
  3. 0

    Dem Papier verbunden zeigt den relevanten code:

    std::unique_ptr<Derived> { new Derived };

    Den gespeicherten deleter ist std::default_delete<Derived>, die nicht erfordern Base::~Base virtuellen werden.


    Jetzt können Sie bewegen dies zu einer unique_ptr<Base>, und es wird auch bewegen Sie den std::default_delete<Derived> ohne Konvertierung in ein std::default_delete<Base>.

    • Ich sehe, es macht Sinn, in der Tat. Vielen Dank an dich und juanchopanza!
    • Eigentlich ist das einzig wahre für std::shared_ptr, nicht std::unique_ptr.
    • Korrigiert match-Papier.
    • Ich würde immer noch den Destruktor virtuell. Es tut nicht weh und wenn jemand nutzt Ihre Klasse in der alten Weise, es wird immer noch funktionieren.
    • Diese nicht funktioniert, nur Basis-Destruktor aufgerufen werden : hier. bewegen tun Sie sich nicht ändern die Art des Empfängers und der deleter ist ein Teil davon. Es würde erfordern type erasure wie shared_ptr andere sonst.
    • Guter Punkt, ich habe versucht, reverse-Engineering, was das Papier wurde argumentiert, und es scheint, viel zu zerbrechlich. Ich glaube nicht, dass Sie brauchen, um die volle Art-Löschung von shared_ptr für die einfache OO-case, aber was unique_ptr bietet, ist in der Tat unzureichend.
    • Ich würde virtuelle dtors auch, aber es kann verletzt. Es könnte eine Art polymorph, falls es noch nicht, die Einführung overhead und möglicherweise Veränderung der Laufzeit-Semantik (typeid und dynamic_cast)
    • Meist, das ist, warum wir C++ - Programmierer in der Regel überspringen Sie die ganzen Zeiger Teil (smart oder nicht) völlig. Aber es gibt make_shared zu halten overhead.
    • Es ist tatsächlich ein problem hier, da einige coding-guidelines wird darauf bestehen, dass die detructors von den abgeleiteten Klassen deklariert werden private ist (so dass Sie nicht versehentlich erstellen eine Instanz auf dem stack).

    InformationsquelleAutor MSalters
Schreibe einen Kommentar