Czy' pusty ' konstruktor lub Destruktor zrobi to samo co wygenerowany?

Zrobi to samo (w zasadzie nic). Ale to nie to samo, jakbyś tego nie napisał. Ponieważ napisanie destruktora będzie wymagało działającego destruktora klasy bazowej. Jeśli Destruktor klasy bazowej jest prywatny lub istnieje inny powód, dla którego nie można go wywołać, to twój program jest uszkodzony. Rozważmy to

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

To jest OK, o ile nie wymagasz niszczenia obiektu typu B (a więc domyślnie typu A) - jak jeśli nigdy nie wywołasz delete na dynamicznie utworzony obiekt, lub nigdy nie tworzysz z niego obiektu w pierwszej kolejności. Jeśli to zrobisz, kompilator wyświetli odpowiednią diagnostykę. Teraz jeśli podasz jeden jawnie

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

Ten spróbuje w domyśle wywołać Destruktor klasy bazowej i spowoduje diagnostykę już w momencie definicji ~B.

Istnieje inna różnica, która koncentruje się wokół definicji destruktora i niejawnych wywołań do destruktorów członkowskich. Rozważ ten inteligentny wskaźnik członek

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

Załóżmy, że obiekt typu C jest tworzony w definicji konstruktora a w pliku .cpp, który zawiera również definicję struct C. Jeśli używasz struct A i wymagasz zniszczenia obiektu A, kompilator dostarczy ukrytą definicję destruktora, tak jak w powyższym przypadku. Ten Destruktor będzie również domyślnie wywoływał Destruktor obiektu auto_ptr. A to usunie trzymany przez niego wskaźnik, który wskazuje na obiekt C - nie znając definicji C! Które pojawiły się w pliku .cpp, w którym zdefiniowany jest konstruktor struct A.

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

Zauważ, że boost::shared_ptr nie ma tego problemu: zamiast tego wymaga typu pełnego, gdy jego konstruktor jest wywoływany w określony sposób.

Innym punktem, w którym robi to różnicę w obecnym C++ jest to, kiedy chcesz użyć memset i znajomych na takim obiekcie, który ma zadeklarowany przez użytkownika Destruktor. Takie typy nie są już PODs (zwykłe stare dane) i nie mogą być kopiowane bitowo. Zauważ, że to ograniczenie nie jest tak naprawdę potrzebne - a następna wersja C++ ma Poprawiono sytuację w tym zakresie, dzięki czemu można nadal kopiować bitowo takie typy, o ile nie zostaną wprowadzone inne ważniejsze zmiany.

Skoro prosiłeś o konstruktorów: cóż, dla tych samych rzeczy są prawdziwe. Zauważ, że konstruktory zawierają również ukryte wywołania destruktorów. Na rzeczach takich jak auto_ptr, wywołania te (nawet jeśli nie są wykonywane w czasie wykonywania - czysta możliwość już tu ma znaczenie) wyrządzą taką samą szkodę jak dla destruktorów i zdarzają się, gdy coś w konstruktor rzuca-kompilator jest wtedy zobowiązany do wywołania destruktora członów. ta odpowiedź wykorzystuje w pewnym stopniu domyślną definicję konstruktorów domyślnych.

To samo dotyczy widoczności i PODness, które powiedziałem o destruktorze powyżej.

Jest jedna ważna różnica w inicjalizacji. Jeśli umieścisz konstruktor zadeklarowany przez użytkownika, Twój typ nie otrzyma już inicjalizacji wartości członków i zależy to od Twojego konstruktor, aby wykonać dowolną inicjalizację, która jest potrzebna. Przykład:

struct A {
    int a;
};

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

W tym przypadku, następujące jest zawsze prawdziwe

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

Podczas gdy poniższe zachowanie jest niezdefiniowane, ponieważ b nigdy nie zostało zainicjowane (Twój konstruktor pominął to). Wartość może być zerowa, ale może również być dowolną inną dziwną wartością. Próba odczytu z tak niezainicjowanego obiektu powoduje nieokreślone zachowanie.

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

Jest to również prawdziwe w przypadku używania tej składni w new, Jak new A() (zwróć uwagę na nawiasy na końcu-jeśli zostaną pominięte, inicjalizacja wartości nie jest wykonywana, a ponieważ nie ma konstruktora zadeklarowanego przez użytkownika, który mógłby ją zainicjować, a pozostanie niezainicjalizowana).