К сожалению, вам приходится указывать тип объектов, удаляемых DeleteObject
(в данном примере Widget
), а это раздражает, vwp
представляет собой vector
— DeleteObject
будет удалять указатели Widget*
! Подобные излишества не только раздражают, но и приводят к возникновению трудно обнаружимых ошибок. Допустим, кто-нибудь по случайности объявляет класс, производный от string
:
class SpecialString: public string{...};
Это рискованно, поскольку string
, как и все стандартные контейнеры STL, не имеет виртуального деструктора, а открытое наследование от классов без виртуального деструктора относится к числу основных табу C++. Подробности можно найти в любой хорошей книге по C++. (В «Effective C++» ищите в совете 14.) И все же некоторые программисты поступают подобным образом, поэтому давайте разберемся, как будет вести себя следующий код:
void doSomething {
deque
for_each(dssp.begin, end, // Непредсказуемое поведение! Удаление
DeleteObject
// на базовый класс при отсутствии
// виртуального деструктора
}
Обратите внимание: dssp
объявляется как контейнер, в котором хранятся указатели SpecialString*
, но автор цикла for_each
сообщает DeleteObject
, что он будет удалять указатели string*
. Понятно, откуда берутся подобные ошибки. По своему поведению SpecialString
имеет много общего со string
, поэтому клиенту легко забыть, что вместо string
он использует SpecialString
.
Чтобы устранить ошибку (а также сократить объем работы для клиентов DeleteObject
), можно предоставить компилятору возможность вычислить тип указания, передаваемого DeleteObject::operator
. Все, что для этого нужно, — переместить определение шаблона из DeleteObject
в operator
:
struct DeleteObject{ // Убрали определение шаблона
// и базовый класс
template
void operator(const T* ptr) const {
delete ptr;
}
};
Компилятор знает тип указателя, передаваемого DeleteObject::operator
, поэтому мы можем заставить его автоматически создать экземпляр operator
для этого типа указателя. Недостаток подобного способа вычисления типа заключается в том, что мы отказываемся от возможности сделать объект DeleteObject
адаптируемым (совет 40). Впрочем, если учесть, на какое применение он рассчитан, вряд ли это можно считать серьезным недостатком.
С новой версией DeleteObject
код клиентов SpecialString
выглядит так:
void doSomething {
deque
...
for_each(dssp.begin, dssp.end,
DeleteObject);// Четко определенное поведение
}
Такое решение прямолинейно и безопасно по отношению к типам, что и требовалось.
Однако безопасность исключений все еще не достигнута. Если исключение произойдет после создания SpecialString
оператором new
, но перед вызовом for_each
, снова произойдет утечка ресурсов. Проблема решается разными способами, но простейший выход заключается в переходе от контейнера указателей к контейнеру
Библиотека STL не содержит умных указателей с подсчетом ссылок. Написание хорошего умного указателя (то есть такого, который бы всегда правильно работал) — задача не из простых, и заниматься ею стоит лишь в случае крайней необходимости. Я привел код умного указателя с подсчетом ссылок в «More Effective C++» в 1996 году. Хотя код был основан на хорошо известной реализации умного указателя, а перед изданием книги материал тщательно проверялся опытными программистами, за эти годы было найдено несколько ошибок. Количество нетривиальных сбоев, возникающих при подсчете ссылок в умных указателях, просто невероятно (за подробностями обращайтесь к списку опечаток и исправлений для книги «More Effective C++» [28]).
К счастью, вам вряд ли придется создавать собственные умные указатели, поскольку найти проверенную реализацию не так сложно. Примером служит указатель shared_ptr
из библиотеки Boost (совет 50). Используя shared_ptr
, можно записать исходный пример данного совета в следующем виде:
void doSomething {