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

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

Однако рассуждения, лежащие в основе “правила большой тройки”, остаются в силе, и это, в сочетании с наблюдением, что объявление копирующей операции исключает неявную генерацию перемещающих операций, обосновывает тот факт, что С++11 не генерирует операции перемещения для класса с пользовательским деструктором.

Таким образом, перемещающие операции генерируются (при необходимости) для классов, только если выполняются три следующие условия:

• в классе не объявлены никакие копирующие операции;

• в классе не объявлены никакие перемещающие операции;

• в классе не объявлен деструктор.

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

class Widget {

public:

…

~Widget(); // Пользовательский деструктор

… // Поведение копирующего

Widget(const Widget&) // конструктора по умолчанию

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

Widget& // Поведение копирующего

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.