Transmogrify(b); // Должна быть ошибка (см. примечание)
Transmogrify(d); // Должна быть ошибка (см. примечание)
Transmogrify2(d); // Все в порядке
Примечание: на момент написания данной рекомендации некоторые компиляторы ошибочно допускали один или оба приведенных вызова функции
Transmogrify
. Эта идиома вполне стандартна, но (пока что) не полностью переносима.
Имеется
лучший способ предупреждения срезки, с более высокой степенью переносимости. Пусть, например, функция наподобие
Transmogrify
в действительности хочет получить полную глубокую копию без информации о действительном производном типе переданного объекта. Более общее идиоматическое решение состоит в том, чтобы сделать копирующий конструктор базового класса защищенным (чтобы функция наподобие
Transmogrify
не могла случайно его вызвать), а вместо него воспользоваться виртуальной функцией
Clone
:
// добавление функции Clone (уже лучше, но все еще требуется
// усовершенствование)
class B { // ...
public:
virtual B* Clone const = 0;
protected:
B(const B&);
};
class D : public B { // ...
public:
virtual D* Clone const { return new D(*this); }
protected:
D( const D& rhs ): B(rhs) {/*...*/ }
};
Теперь попытка срезки будет (переносимо) генерировать ошибку времени компиляции, а объявление функции
Clone
как чисто виртуальной заставляет непосредственный производный класс перекрыть ее. К сожалению, с данным решением все еще связаны две проблемы, которые компилятор не в состоянии обнаружить: в классе, производном от производного, функция
Clone
может оказаться неперекрытой, а перекрытие
Clone
может реализовать ее некорректно, так что копия будет не того же типа, что и оригинал. Функция
Clone
должна следовать шаблону проектирования Nonvirtual Interface (NVI; см. рекомендацию 39), который разделяет открытую и виртуальную природы
Clone
и позволяет вам использовать ряд важных проверок:
class В { // ...
publiс:
B* Clone const { // Невиртуальная функция
B* р = DoClone;
assert(typeid(*p) == typeid(*this) &&
"DoClone incorrectly overridden");
return p; // проверка типа, возвращаемого DoClone
}
protected:
B(const B&);
private:
virtual B* DoClone const = 0;
};
Функция
Clone
теперь является невиртуальным интерфейсом, используемым вызывающим кодом. Производные классы должны перекрыть функцию
DoClone
. Дополнительная проверка обнаружит все копии, которые имеют тип, отличный от оригинала, тем самым оповещая, что в некотором
производном классе не перекрыта функция
DoClone
; в конце концов, задача
assert
состоит именно в обнаружении и сообщении о таких программных ошибках (см. рекомендации 68 и 70).
Исключения
Некоторые проектные решения могут требовать, чтобы копирующие конструкторы базовых классов оставались открытыми (например, когда часть вашей иерархии представляет собой библиотеку стороннего производителя). В таком случае следует предпочесть передачу посредством (интеллектуального) указателя передаче по ссылке; как показано в рекомендации 25, передача посредством указателя существенно менее подвержена срезке и нежелательному созданию временных объектов.
предпочитайте использовать канонический вид — невиртуальный с определенной сигнатурой.
Обсуждение
Предпочтительно объявлять копирующее присваивание для типа
T
с одной из следующих сигнатур (см. [Stroustrup00] и [Alexandrescu03a]):
T& operator=(const T&); // классический вид
T& operator=(T); // потенциально оптимизированный
// вид (см. рекомендацию 27)
Второй вариант имеет смысл использовать, если вам в любом случае требуется копия аргумента в теле вашего оператора, как, например, при использовании идиомы, основанной на использовании функции обмена (см. рекомендацию 56).
Избегайте делать любой оператор присваивания виртуальным (см. [Meyers96] §33 и [Sutter04] §19). Если вы полагаете, что вам требуется виртуальное поведение присваивания, обратитесь сначала к указанной литературе. Если и после этого вы стоите на своем, то лучше использовать виртуальную именованную функцию, а не оператор (например,
virtual void Assign(const T&);
).
He возвращайте
const T&
. Хотя этот тип возвращаемого значения имеет то преимущество, что защищает от странных присваиваний наподобие
(a=b)=c
, главным его недостатком является то, что вы не сможете поместить объекты типа
T
в контейнеры стандартной библиотеки; эти контейнеры требуют, чтобы оператор присваивания возвращал тип
T&
.
Всегда делайте копирующее присваивание безопасным в смысле исключений, причем предпочтительна строгая гарантия (см. рекомендацию 71).
Убедитесь, что ваш оператор присваивания безопасен в смысле присваивания самому себе. Избегайте написания оператора копирующего присваивания, который для корректной работы полагается на проверку присваивания самому себе; зачастую это говорит о недостаточной безопасности в смысле исключений. Если вы пишете копирующее присваивание с использованием идиомы обмена (см. рекомендацию 56), то вы автоматически обеспечиваете как строгую безопасность в смысле исключений, так и безопасность в смысле присваивания самому себе. Если присваивание самому себе часто встречается в программе из-за использования ссылочных синонимов или по каким-то иным причинам, проверка присваивания самому себе может использоваться в качестве средства оптимизации во избежание лишней работы.