Скотт Мейерс - Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14

operator=(const Widget&) // присваивания по умолчанию

= default; // правильное

};

Этот подход часто полезен в полиморфных базовых классах, т.e. в классах, определяющих интерфейсы, посредством которых происходит управление производными классами. Обычно полиморфные базовые классы имеют виртуальные деструкторы, поскольку, если это не так, некоторые операции (например, использование deleteили typeidс объектом производного класса через указатель или ссылку на базовый класс) дают неопределенный или вводящий в заблуждение результат. Если только класс не наследует деструктор, являющийся виртуальным, единственный способ сделать деструктор виртуальным — явно объявить его таковым. Зачастую реализация по умолчанию является корректной, и использовать конструкции “ = default” — хороший способ выразить это. Однако пользовательский деструктор подавляет генерацию перемещающих операций, так что, если требуется поддержка перемещаемости, “ = default” зачастую находит второе применение. Объявление перемещающих операций отключает копирующие операции, так что, если копируемость также желательна, это делает еще один круг “ = default”:

class Base {

public:

virtual~Base() = default; // Делает деструктор виртуальным

Base(Base&&) = default; // Поддержка перемещения

Base& operator=(Base&&) = default;

Base(const Base&) = default;// Поддержка копирования

Base& operator=(const Base&) = default;

};

Фактически, даже если у вас есть класс, в котором компиляторы могут генерировать копирующие и перемещающие операции и в котором генерируемые функции ведут себя так, как надо, вы можете выбрать стратегию их объявления и применения конструкции “ = default” в качестве определений. Это требует большего количества работы, но делает ваши намерения более ясными, и это может помочь обойти некоторые довольно трудно выявляемые ошибки. Предположим, например, что у нас есть класс, представляющий таблицу строк, т.e. структуру данных, которая обеспечивает быстрый поиск строкового значения по его целочисленному идентификатору:

class StringTable {

public:

StringTable() {}

// Функции вставки, удаления, поиска и т.п., но нет

// функциональности копирования/перемещения/деструкции

private:

std::map values;

};

Предположим, что в классе не объявлены ни копирующие операции, ни перемещающие операции, ни деструктор, так что компиляторы автоматически сгенерируют эти функции при их использовании. Это очень удобно.

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

class StringTable {

public:

StringTable()

{ makeLogEntry("Создание StringTable"}; } // Добавлено

~StringTable()

{ mаkеLоgЕntrу("Уничтожение StringTable"); } // Добавлено

… // Прочие функции,

private: // как и раньше

std::map values; // Как и раньше

};

Выглядит разумно, но объявление деструктора потенциально имеет важное побочное действие: оно предотвращает генерацию перемещающих операций. Создание класса на эти операции не влияет. Таким образом, код, вероятно, будет без проблем компилироваться, выполняться и проходить функциональное тестирование.

Сюда включается и тестирование функциональности перемещения, поскольку, хотя даже этот класс и не является перемещаемым, запрос на перемещение будет компилироваться и работать. Такой запрос, как отмечалось ранее в данном разделе, приводит к выполнению копирования. Это означает, что код, “перемещающий” объекты StringTable, в действительности их копирует, т.e. копирует лежащие в их основе объекты std::map. А копирование std::map, скорее всего, окажется на порядки медленнее перемещения. Простое добавление деструктора к классу может тем самым внести значительные проблемы, связанные с производительностью! Если бы копирующие и перемещающие операции были явно определены как “ = default”, такая проблема не могла бы возникнуть.

Теперь, благополучно пережив мою бесконечную болтовню о правилах, управляющих операциями копирования и перемещения в С++11, вы можете озадачиться: когда же я, наконец, обращу свое внимание на две другие специальные функции — конструктор по умолчанию и деструктор? Да прямо сейчас, в этом предложении, и только в нем, потому что для этих функций-членов почти ничего не изменилось: правила в С++11 практически те же, что и в С++98.