Wird ein 'leerer' Konstruktor oder Destruktor dasselbe tun wie das generierte?

Wird es nicht die gleiche Sache (nichts, im wesentlichen). Aber es ist nicht das gleiche, wie wenn Sie nicht es zu schreiben. Da schreiben Sie den Destruktor benötigen eine funktionierende Basis-Klasse Destruktor. Wenn die Basisklasse destructor privat ist oder wenn es einen anderen Grund kann es nicht aufgerufen werden, dann ist dein Programm fehlerhaft ist. Betrachten Sie dieses

struct A { private: ~A(); };
struct B : A { }; 

Dass ist OK, solange Ihr nicht verlangen, zu zerstören, ein Objekt des Typs B (und damit implizit der Typ A) - wie wenn Sie nie rufen Sie löschen auf einem dynamisch erzeugten Objekt, oder Sie erstellen Sie niemals ein Objekt, der es in den ersten Platz. Wenn Sie das tun, dann wird der compiler zeigt eine entsprechende Diagnose. Nun, wenn Sie sorgen, dass man sich ausdrücklich

struct A { private: ~A(); };
struct B : A { ~B() { /* ... */ } }; 

Dass man versuchen wird implizit rufen Sie den Destruktor der Basis-Klasse, und zu bewirken, dass eine Diagnose bereits bei der Bestimmung der Zeit der ~B.

Es ist ein weiterer Unterschied, der dreht sich um die definition des destruktors und implizite Aufrufe Mitglied Destruktoren. Betrachten Sie dieses smart pointer Mitglied

struct C;
struct A {
    auto_ptr<C> a;
    A();
};

Nehmen wir an, das Objekt vom Typ C erstellt wird, in der definition von Einem Konstruktor in der .cpp - Datei, die enthält auch die definition von struct C. Nun, wenn Sie mit struct A erfordern und Zerstörung einer A Objekt, der compiler wird eine implizite definition der Destruktor, so wie in dem Fall oben. Dass der Destruktor wird implizit auch rufen Sie den Destruktor der auto_ptr-Objekt. Und, löschen den Zeiger, er hält sich, dass Punkte, die C Objekt - ohne zu wissen, die definition von C! Erschienen in der .cpp - Datei, in dem struct Einen Konstruktor definiert ist.

Dies ist tatsächlich ein häufiges problem in der Implementierung des pimpl-idiom. Die Lösung hier ist das hinzufügen von ein Destruktor und einer leeren definition in der .cpp - Datei, wobei die Struktur C definiert ist. Zu der Zeit, es ruft den Destruktor seiner Mitglieder, er wird dann wissen, die definition von struct Cund können richtig nennen, der Destruktor.

struct C;
struct A {
    auto_ptr<C> a;
    A();
    ~A(); //defined as ~A() { } in .cpp file, too
};

Beachten Sie, dass boost::shared_ptr nicht haben, dass problem: Es stattdessen Bedarf es eines ganzheitlichen geben, wenn der Konstruktor aufgerufen wird, in gewisser Weise.

Einem anderen Punkt, wo es macht einen Unterschied in der aktuelle C++ ist, wenn Sie verwenden möchten memset und Freunde auf so ein Objekt, einen Benutzer deklarierten Destruktor. Solche Typen sind keine Hülsen mehr (plain old data), und diese sind nicht zulässig bit-kopiert. Beachten Sie, dass diese Einschränkung ist nicht wirklich notwendig - und das nächste C++ - version hat sich verbessert, die situation auf diesem, so dass es erlaubt Ihnen, die noch wenig-kopieren Sie solche Typen, solange andere, wichtigere änderungen werden nicht vorgenommen.

Seit Ihr gefragt für Konstruktoren: Gut, für diese viel die gleichen Dinge, die wahr sind. Beachten Sie, dass Konstruktoren enthalten ebenfalls implizite Aufrufe von Destruktoren. Auf Dinge wie auto_ptr, diese Anrufe (auch wenn Sie nicht tatsächlich erfolgt zur Laufzeit - die Reine Möglichkeit schon geht es hier) machen den gleichen Schaden wie für Destruktoren, und passiert, wenn etwas in den Konstruktor wirft - der compiler ist dann erforderlich, rufen Sie den Destruktor der Mitglieder. Diese Antwort macht die Verwendung von impliziten definition von default-Konstruktoren.

Auch, das gleiche gilt für die Sichtbarkeit und PODness, dass ich sagte, über den Destruktor oben.

Gibt es einen wichtigen Unterschied bezüglich der Initialisierung. Wenn Sie einen Benutzer deklarierten Konstruktor Ihre Art nicht erhalten Wert Initialisierung der member mehr, und es ist bis zu Ihrem Konstruktor zu tun, keine Initialisierung nötig. Beispiel:

struct A {
    int a;
};

struct B {
    int b;
    B() { }
};

In diesem Fall die folgende ist immer wahr

assert(A().a == 0);

Während der folgenden ist Undefiniertes Verhalten, weil b wurde nie initialisiert (der Konstruktor weggelassen). Der Wert kann null sein, kann aber auch andere komisch Wert. Versucht zu Lesen, von so einer nicht initialisierten Objekt führt zu undefiniertem Verhalten.

assert(B().b == 0);

Dies gilt auch für die Verwendung dieser syntax bei new wie new A() (beachten Sie die Klammern am Ende - werden Sie weggelassen Wert die Initialisierung nicht durchgeführt wird, und da gibt es keinen user-deklarierten Konstruktor, könnte es initialisieren, a verlassen wird, nicht initialisiert).

InformationsquelleAutor der Antwort Johannes Schaub - litb

Den leeren Destruktor, die Sie definiert, die aus der Klasse hat eine ähnliche Semantik in Bezug auf die meisten, aber nicht in allen.

Explizit, die implizit definierte Destruktor

1) ist ein inline public-member (Ihr nicht inline)

2) wird bezeichnet als trivial destructor (notwendig, um triviale Arten, die in Gewerkschaften, yours nicht)

3) ist eine Ausnahme-Spezifikation (throw(), yours nicht)

InformationsquelleAutor der Antwort Faisal Vali

Ich Stimme mit David außer, dass ich würde sagen, es ist generell eine gute Praxis, definieren Sie einen virtuellen Destruktor d.h.

virtual ~Foo() { }

verpassen virtuelle Destruktor kann zu Speicherverlust führen, weil Menschen, die Erben von deiner Klasse " Foo " kann nicht bemerkt haben, dass Ihr Destruktor nie aufgerufen!!

InformationsquelleAutor der Antwort oscarkuo

Einer leeren definition ist in Ordnung, da die definition verwiesen werden kann

virtual ~GameManager() { };

Die leere Erklärung ist täuschend ähnlich in Aussehen

virtual ~GameManager();

noch lädt der gefürchtete keine definition für virtuelle Destruktor Fehler

Undefined symbols:
  "vtable for GameManager", referenced from:
      __ZTV11GameManager$non_lazy_ptr in GameManager.o
      __ZTV11GameManager$non_lazy_ptr in Main.o
ld: symbol(s) not found

InformationsquelleAutor der Antwort