• Управляющие ресурсами объекты используют свои деструкторы для гарантии освобождения ресурсов. Поскольку деструктор вызывается автоматически при уничтожении объекта (например, когда объект выходит из области действия), ресурсы корректно освобождаются независимо от того, как управление покидает блок. Ситуация осложняется, когда в ходе освобождения ресурса может возникнуть исключение, но эта тема обсуждается в правиле 8, поэтому сейчас мы о ней говорить не будем.
Так как деструктор auto_ptr автоматически удаляет то, на что указывает, важно, чтобы ни в какой момент времени не существовало более одного auto_ptr, указывающего на один и тот же объект. Если такое случается, то объект будет удален более одного раза, что обязательно приведет к неопределенному поведению. Чтобы предотвратить такие проблемы, объекты auto_ptr обладают необычным свойством: при копировании (посредством копирующих конструкторов или операторов присваивания) внутренний указатель в старом объекте становится равным нулю, а новый объект получает ресурс в свое монопольное владение!
>std::auto_ptr // pInv1 указывает на объект,
>pInv1(createInvestment()); // возвращенный createInvestment()
>std::auto_ptr pInv2(pInv1); // pInv2 теперь указывает на объект,
>// а pInv1 равен null
>pInv1 = pInv2; // теперь pInv1 указывает на объект,
>// а pInv2 равно null
Это странное поведение при копировании плюс лежащее в его основе требование о том, что ни на какой ресурс, управляемый auto_ptr, не должен указывать более чем один auto_ptr, означает, что auto_ptr – не всегда является наилучшим способом управления динамически выделяемыми ресурсами. Например, STL-контейнеры требуют, чтобы их содержимое при копировании вело себя «нормально», поэтому помещать в них объекты auto_ptr нельзя.
Альтернатива auto_ptr – это интеллектуальные указатели с подсчетом ссылок (reference-counting smart pointer – RCSP). RCSP – это интеллектуальный указатель, который отслеживает, сколько объектов указывают на определенный ресурс, и автоматически удаляет ресурс, когда никто на него не ссылается. Следовательно, RCSP ведет себя подобно сборщику мусора. Но, в отличие от сборщика мусора, RCSP не может разорвать циклические ссылки (когда два неиспользуемых объекта указывают друг на друга).
Класс tr1::shared_prt из библиотеки TR1 (см. правило 54) – это типичный пример RCSP, поэтому вы можете написать:
>void f()
>{
>...
>std::tr1::shared_ptr
