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

Вероятно, вы слышали о рекомендации о большой тройке. Она утверждает, что если вы объявили хотя бы одну из трех операций — копирующий конструктор, копирующий оператор присваивания или деструктор, — то вы должны объявить все три операции. Это правило вытекает из наблюдения, что необходимость изменения смысла копирующей операции почти всегда подразумевает, что (1) какое бы управление ресурсами не выполнялось в одной копирующей операции, вероятно, такое же управление ресурсами потребуется и во второй копирующей операции; и (2) деструктор класса также должен участвовать в управлении ресурсами (обычно — освобождать их). Классическим управляемым ресурсом является память, и именно поэтому все классы стандартной библиотеки, управляющие памятью (например, контейнеры STL, управляющие динамической памятью), объявляют всю “большую тройку”: обе копирующие операции и деструктор.

Следствием правила большой тройки является то, что наличие пользовательского деструктора указывает на вероятную неприменимость простого почленного копирования для копирующих операций класса. Это, в свою очередь, предполагает, что если класс объявляет деструктор, то копирующие операции, по всей вероятности, не должны генерироваться автоматически, так как они будут выполнять неверные действия. Во времена принятия С++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. структуру данных, которая обеспечивает быстрый поиск строкового значения по его целочисленному идентификатору: