Будет 'пустой' конструктор или деструктор делают то же самое как сгенерированное?

Он будет делать то же самое (по сути, ничего). Но это не то же самое, если бы вы этого не писали. Потому что для написания деструктора потребуется рабочий деструктор базового класса. Если деструктор базового класса является частным или по какой-либо другой причине он не может быть вызван, ваша программа неисправна. Считайте это

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

. Это нормально, если вам не требуется разрушать объект типа B (и, следовательно, неявно типа A) - например, если вы никогда не вызываете delete для динамически создаваемого объекта или никогда не создаете объект его в первую очередь. Если вы это сделаете, то компилятор отобразит соответствующую диагностику. Теперь, если вы предоставите один явно

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

, он попытается неявно вызвать деструктор базового класса и вызовет диагностику уже во время определения ~ B .

Есть еще одно различие, которое связано с определением деструктора и неявными вызовами деструкторов членов. Рассмотрим этот член интеллектуального указателя

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

. Предположим, что объект типа C создан в определении конструктора A в файле .cpp , который также содержит определение struct C . Теперь, если вы используете struct A и требуете уничтожения объекта A , компилятор предоставит неявное определение деструктора, как и в случае выше. Этот деструктор также неявно вызовет деструктор объекта auto_ptr. И это приведет к удалению содержащегося в нем указателя, который указывает на объект C - без знания определения C ! Это появилось в . cpp файл, в котором определен конструктор структуры A.

На самом деле это обычная проблема при реализации идиомы pimpl. Решением здесь является добавление деструктора и предоставление его пустого определения в файле .cpp , где определена структура C . В то время, когда он вызывает деструктор своего члена, он будет знать определение struct C и сможет правильно вызвать его деструктор.

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

Обратите внимание, что boost :: shared_ptr не имеет этой проблемы: вместо этого требуется полный тип, когда его конструктор вызывается определенными способами.

Другой момент, в котором это имеет значение в текущем C ++, - это когда вы хотите использовать memset и его друзей для такого объекта, у которого есть объявленный пользователем деструктор. Такие типы больше не являются POD (простые старые данные), и их нельзя копировать побитно. Обратите внимание, что это ограничение на самом деле не требуется - и следующая версия C ++ улучшила ситуацию в этом отношении, так что она позволяет вам по-прежнему копировать такие типы в битах до тех пор, пока не будут внесены другие более важные изменения.

Поскольку вы просили о конструкторах: Что ж, в этом смысле то же самое. Обратите внимание, что конструкторы также содержат неявные вызовы деструкторов. В таких вещах, как auto_ptr, эти вызовы (даже если они фактически не выполняются во время выполнения - чистая возможность здесь уже имеет значение) нанесут тот же вред, что и для деструкторов, и произойдут, когда что-то в конструкторе выбрасывает - компилятор затем должен вызвать деструктор членов. В этом ответе используется неявное определение конструкторов по умолчанию.

Также, то же самое верно для видимости и PODness, что я сказал о деструкторе выше.

Есть одно важное различие относительно инициализации. Если вы поместите объявленный пользователем конструктор, ваш тип больше не получит инициализацию значений членов, и ваш конструктор должен выполнить любую необходимую инициализацию. Пример:

struct A {
    int a;
};

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

В этом случае всегда верно следующее

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

В то время как следующее является неопределенным поведением, потому что b никогда не инициализировался (ваш конструктор это пропустил). Значение может быть нулем, но также может быть любое другое странное значение. Попытка чтения из такого неинициализированного объекта вызывает неопределенное поведение.

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

Это также верно для использования этого синтаксиса в new , например new A () (обратите внимание на круглые скобки в конце - если они опущены, инициализация значения не выполняется,