Читать онлайн «Стандарты программирования на С++. 101 правило и рекомендация». Страница 29

[C++03] §15.2(3), §17.4.4.8(3) • [Meyers96] §11 • [Stroustrup00] §14.4.7, §E.2-4 • [Sutter00] §8, §16 • [Sutter02] §18-19

Если вы определили одну из следующего списка функций — копирующий конструктор, оператор копирующего присваивания или деструктор — вероятно, вам потребуется определить и обе оставшиеся функции (или по крайней мере одну из них).

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

• Если вы пишете или запрещаете копирующий конструктор или оператор копирующего присваивания, то, вероятно, вы должны сделать то же самое и для другой функции из этой пары. Если одна функция выполняет некоторую "специальную" работу, вероятно, другая должна делать что-то аналогичное, так как эти две функции должны иметь одинаковое действие (см. рекомендацию 53, которая поясняет этот пункт).

• Если вы явно пишете копирующие функции, вероятно, вам надо явно написать и деструктор. Если "специальная" работа в копирующем конструкторе заключается в выделении или дублировании некоторого ресурса (например, памяти, файла, сокета), то вы должны освободить этот ресурс в деструкторе.

• Если вы явно пишете деструктор, вероятно, вам требуется явно написать (или явно запретить) копирование. Если вам нужен нетривиальный деструктор, это зачастую связано с тем, что вам требуется вручную освободить ресурс, хранящийся объектом. Если так, вероятно, для этого ресурса требуется аккуратное дублирование, так что вам следует уделить внимание способу копирования и присваивания объектов, либо полностью запретить таковое.

Во многих случаях хранение корректно инкапсулированного ресурса с использованием идиомы RAII позволяет полностью избежать самостоятельной разработки указанных операций (см. рекомендацию 13).

Предпочитайте специальные члены, сгенерированные компилятором. Только они могут рассматриваться как "тривиальные", и как минимум один крупный производитель STL использует оптимизацию для классов с тривиальными специальными функциями. Похоже, вскоре это станет распространенным явлением.

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

В редких случаях классы, имеющие члены странных типов (например, ссылки, std::auto_ptr), являются исключениями, поскольку они имеют необычную семантику копирования. В классе, хранящем ссылку или auto_ptr, вам, вероятно, потребуется написать копирующий конструктор и оператор присваивания, но деструктор по умолчанию будет работать корректно. (Заметим, что использование члена, являющегося ссылкой или auto_ptr, почти всегда ошибочно).

[Cline99] §30.01-14 • [Koenig97] §4 • [Stroustrup00] §5.5, §10.4 • [SuttHysl04b]

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

Распространенной ошибкой (и не только среди новичков) является игнорирование семантики копирования и присваивания при определении класса. Это характерно для маленьких вспомогательных классов, таких как предназначенные для поддержки идиомы RAII (см. рекомендацию 13).

Убедитесь, что ваш класс предоставляет осмысленное копирование (или не предоставляет его вовсе). Вот возможные варианты.

• Явное запрещение обеих функций. Если копирование для вашего типа лишено смысла, запретите как копирующее конструирование, так и копирующее присваивание, объявив их как закрытые нереализованные функции:

class T { // ...

private:                 // Делаем T некопируемым

 T(const T&);            // Функция не реализована

 T& operator=(const T&); // Функция не реализована

};

• Явное написание обеих функций. Если для объектов T предусмотрены копирование и копирующее присваивание, но корректное копирующее поведение отличается от поведения сгенерированных компилятором версий, то следует явно написать обе функции и сделать их не закрытыми.

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

Заметим, что запрещение копирования и копирующего присваивания означает, что вы не можете поместить объекты T в стандартные контейнеры. Это не обязательно плохо; очень может быть, что вы в любом случае не захотите хранить такие объекты в контейнерах. (Тем не менее, вы все равно можете поместить эти объекты в контейнер, если будете хранить их посредством интеллектуальных указателей; см. рекомендацию 79).

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

[Dewhurst03] §88 • [Meyers97] §11 • [Stroustrup00] §11.2.2

Срезка объектов происходит автоматически, невидимо и может приводить к полному разрушению чудесного полиморфного дизайна. Подумайте о полном запрете копирующего конструктора и копирующего присваивания в базовых классах. Вместо них можно использовать виртуальную функцию-член Clone, если пользователям вашего класса необходимо получать полиморфные (полные, глубокие) копии.

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

class B { /* ... */ };

class D : public B { /* ... */ };

// Оп! Получение объекта по значению

void Transmogrify(B obj);

void Transubstantiate(B& obj) { // Все нормально -

                                // передача по ссылке

 Transmogrify(obj);             // Плохо! Срезка объекта!

 // ...

}

D d;

Transubstantiate(d);

Программист намерен работать с объектами В и производных классов полиморфно. Однако, по ошибке (или усталости — к тому же и кофе закончился…) программист или просто забыл написать & в сигнатуре Transmogrify, или собирался создать копию, но сделал это неверно. Код компилируется без ошибок, но когда функция Transmogrify вызывается с передачей ей объекта D, он мутирует в объект B. Это связано с тем, что передача по значению приводит к вызову B::В(const B&), т.е. копирующего конструктора В, параметр которого const B& представляет собой автоматически преобразованную ссылку на d. Что приводит к полной потере динамического, полиморфного поведения, из-за которого в первую очередь и используется наследование.

Если, как автор класса В, вы хотите разрешить срезку, но не хотите, чтобы она могла происходить по ошибке, для такого случая существует один вариант действий, о котором мы упомянем для полноты изложения, но не рекомендуем использовать его в коде, к которому предъявляется требование переносимости: вы можете объявить копирующий конструктор В как explicit. Это может помочь избежать неявной срезки, но кроме этого запрещает все передачи параметров данного типа по значению (что может оказаться вполне приемлемым для базовых классов, объекты которых все равно не должны создаваться; см. рекомендацию 35).

// Объявляем копирующий конструктор как explicit (у данного

// решения имеется побочное действие, так что требуется

// улучшение этого метода)

class B { // ...

public: