class SmartPtr {
public:
explicit SmartPtr(T *realPtr); // интеллектуальные указатели обычно
... // инициализируются встроенными
}; // указателями
SmartPtrTop pt1 = // преобразует SmartPtrMiddle
SmartPtrMiddle(new Middle); // в SmartPtrTop
SmartPtrTop pt2 = // преобразует SmartPtrBottom
SmartPtrBottom(new Bottom); // SmartPtrTop
SmartPtrconst Top pct2 = pt1;
Разные конкретизации одного шаблона не связаны каким-либо отношением, поэтому компилятор считает, что SmartPtrMiddle и SmartPtrTop – совершенно разные классы, не более связанные друг с другом, чем, например, vectorfloat и Widget. Чтобы можно было осуществлять преобразования между разными классами SmartPtr, необходимо явно написать соответствующий код. В приведенном выше примере каждое предложение создает новый объект интеллектуального указателя, поэтому для начала сосредоточимся на написании конструкторов, которые будут вести себя так, как нам нужно. Ключевое наблюдение состоит в том, что невозможно написать сразу все необходимые конструкторы. В приведенной иерархии мы можем сконструировать SmartPtrTop из SmartPtrMiddle или SmartPtrBottom, но если в будущем иерархия будет расширена, то придется добавить возможность конструирования объектов SmartPtrTop из других типов интеллектуальных указателей. Например, если мы позже добавим такой класс:
class BelowBottom: public Bottom {...};
то нужно будет поддержать создание объектов SmartPtrTop из SmartPtrBelow-Bottom, и, очевидно, не хотелось бы ради этого модифицировать шаблон SmartPtr.
В принципе, нам может понадобиться неограниченное число конструкторов. Поскольку шаблон может быть конкретизирован для генерации неограниченного числа функций, похоже, что нам нужен не
templatetypename T
class SmartPtr {
public:
templatetypename U // шаблонный член
SmartPtr(const SmartPtrU other); // для «обобщенного
... // конструктора копирования»
};
Здесь говорится, что для каждой пары типов T и U класс SmartPtrT может быть создан из SmartPtrU, потому что SmartPtrT имеет конструктор, принимающий параметр типа SmartPtrU. Подобные конструкторы, создающие один объект из другого, тип которого является другой конкретизацией того же шаблона (например, SmartPtrT из SmartPtrU), иногда называют
Обобщенный конструктор копирования в приведенном выше примере не объявлен с модификатором explicit. И это сделано намеренно. Преобразования типов между встроенными типами указателей (например, из указателя на производный класс к указателю на базовый класс) происходят неявно и не требуют приведения, поэтому разумно и для интеллектуальных указателей эмулировать такое поведение. Именно поэтому и не указано слово explicit в объявлении обобщенного конструктора шаблона.
Будучи объявлен описанным выше образом, обобщенный конструктор копирования для SmartPtr предоставляет больше, чем нам нужно. Да, мы хотим иметь возможность создавать SmartPtrTop из SmartPtrBottom, но вовсе не просили создавать SmartPtrBottom из SmartPtrTop, потому что это противоречит смыслу открытого наследования (см. правило 32). Мы также не хотим создавать SmartPtrint из SmartPtrdouble, потому что не существует неявного преобразования int* в double*. Каким-то образом мы должны сузить многообразие функций-членов, которые способен генерировать этот шаблон.
Предполагая, что SmartPtr написан по образцу auto_ptr и tr1::shared_ptr, то есть предоставляет функцию-член get, которая возвращает копию встроенного указателя, хранящегося в объекте «интеллектуального» указателя (см. правило 15), мы можем воспользоваться реализацией шаблонного конструктора, чтобы ограничить набор преобразований:
templatetypename T
class SmartPtr {
public:
templatetypename U
SmartPtr(const SmartPtrU other) // инициировать этот хранимый
:heldPtr(other.get) {...} // указатель указателем, хранящимся
// в другом объекте
T *get const { return heldPtr;}
...
private: // встроенный указатель,