Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ

Будучи объявлен описанным выше образом, обобщенный конструктор копирования для SmartPtr предоставляет больше, чем нам нужно. Да, мы хотим иметь возможность создавать SmartPtr из SmartPtr, но вовсе не просили создавать SmartPtr из SmartPtr, потому что это противоречит смыслу открытого наследования (см. правило 32). Мы также не хотим создавать SmartPtr из SmartPtr, потому что не существует неявного преобразования int* в double*. Каким-то образом мы должны сузить многообразие функций-членов, которые способен генерировать этот шаблон.

Предполагая, что SmartPtr написан по образцу auto_ptr и tr1::shared_ptr, то есть предоставляет функцию-член get, которая возвращает копию встроенного указателя, хранящегося в объекте «интеллектуального» указателя (см. правило 15), мы можем воспользоваться реализацией шаблонного конструктора, чтобы ограничить набор преобразований:

template

class SmartPtr {

public:

template

SmartPtr(const SmartPtr& other) // инициировать этот хранимый

:heldPtr(other.get()) {...} // указатель указателем, хранящимся

// в другом объекте

T *get() const { return heldPtr;}

...

private: // встроенный указатель,

T *heldPtr; // хранящийся в «интеллектуальном»

};

Мы используем список инициализации членов, чтобы инициализировать член данных SmartPtr типа T* указателем типа U*, который хранится в Smart-Ptr. Этот код откомпилируется только тогда, когда существует неявное преобразование указателя U* в T*, а это как раз то, что нам нужно. Итак, SmartPtr теперь имеет обобщенный копирующий конструктор, который компилируется только тогда, когда ему передается параметр совместимого типа.

Использование шаблонных функций-членов не ограничивается конструкторами. Еще одно полезное применение таких функций – поддержка присваивания. Например, класс shared_ptr из TR1 (см. правило 13) поддерживает конструирование из всех совместимых встроенных указателей, tr1::shared_ptr, auto_ptr и tr1::weak_ptr (см. правило 54), а также наличие в правой части оператора присваивания объекта любого из этих типов, кроме tr1::weak_ptr. Ниже приведен фрагмент спецификации TR1 для tr1::shared_ptr; обратите внимание, что при объявлении параметров шаблона используется ключевое слов class, а не typename. Как объясняется в правиле 42, в данном контексте они означают одно и то же.

template class shared_ptr {

public:

template // конструирует из

explicit shared_ptr(Y *p); // любого совместимого

template // встроенного указателя,

shared_ptr(shared_ptr const& r); // shared_ptr,

template // weak_ptr или

explicit shared_ptr(weak_ptr const& r); // auto_ptr

template

explicit shared_ptr(auto_ptr& r);

template // присваивает

explicit shared_ptr& operator=(shared_ptr const& r); // любой

template // совместимый

explicit shared_ptr& operator=(auto_ptr const& r); // shared_ptr или

... // auto_ptr

};

Все эти конструкторы объявлены как explicit, за исключением обобщенного конструктора копирования. Это значит, что неявные преобразования от одного типа shared_ptr к другому допускаются, но неявные преобразования от встроенного указателя или другого «интеллектуального» указателя не допускаются. (Явные преобразования – например, с помощью приведения типов – разрешены). Также интересно отметить, что при передаче объекта auto_ptr конструктору tr1::shared_ptr и оператору присваивания параметр указывается без модификатора const, тогда как передаваемые параметры типа tr1::shared_ptr и tr1::weak_ptr константны. Это следствие того факта, что в отличие от других классов объекты auto_ptr модифицируются при копировании (см. правило 13).