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