Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14 - [57]

auto pw = new Widget;   // pw - обычный указатель
…
std::shared_ptr
 spw1(pw, loggingDel);  // Создание управляющего блока для *pw
…
std::shared_ptr // Создание второго
 spw2(pw, loggingDel);  // управляющего блока для *pw!

Создание обычного указателя pw, указывающего на динамически выделенный объект, — плохое решение, поскольку оно противоречит главному совету всей главы: предпочитайте интеллектуальные указатели обычным указателям. (Если вы забыли, откуда взялся этот совет, заново прочтите первую страницу данной главы.) Но пока что забудем об этом. Строка, в которой создается pw, представляет собой стилистическую мерзость, но она по крайней мере не приводит к неопределенному поведению.

Далее вызывается конструктор для spw1, которому передается обычный указатель, так что этот конструктор создает управляющий блок (и тем самым счетчик ссылок) для того, на что он указывает. В данном случае это *pw (т.e. объект, на который указывает pw). Само по себе это не является чем-то страшным, но далее с тем же обычным указателем вызывается конструктор для spw2, и он также создает управляющий блок (а следовательно, и счетчик ссылок) для *pw. Объект *pw, таким образом, имеет два счетчика ссылок, каждый из которых в конечном итоге примет нулевое значение, и это обязательно приведет к попытке уничтожить объект *pw дважды. Второе уничтожение и будет ответственно за неопределенное поведение.

Из этого можно вынести как минимум два урока, касающиеся применения std::shared_ptr. Во-первых, пытайтесь избегать передачи обычных указателей конструктору std::shared_ptr. Обычной альтернативой этому является применение функции std::make_shared (см. раздел 4.4), но в примере выше мы использовали пользовательские удалители, а это невозможно при использовании std::make_shared. Во-вторых, если вы вынуждены передавать обычный указатель конструктору std::shared_ptr, передавайте непосредственно результат оператора new, а не используйте переменную в качестве посредника. Если первую часть кода переписать следующим образом,

std::shared_ptr
 spw1(new Widget, // Непосредственное использование new
      loggingDel);

то окажется гораздо труднее создать второй std::shared_ptr из того же обычного указателя. Вместо этого автор кода, создающего spw2, естественно, будет использовать в качестве аргумента инициализации spw1 (т.e. будет вызывать копирующий конструктор std::shared_ptr), и это не будет вести ни к каким проблемам:

std::shared_ptr // spw2 использует тот же
 spw2(spw1);            // управляющий блок, что и spw1

Особенно удивительный способ, которым применение переменных с обычными указателями в качестве аргументов конструкторов std::shared_ptr может привести к множественным управляющим блокам, включает указатель this. Предположим, что наша программа использует указатели std::shared_ptr для управления объектами Widget и у нас есть структура данных, которая отслеживает объекты Widget, которые были обработаны:

std::vector<std::shared_ptr> processedWidgets;

Далее, предположим, что Widget имеет функцию-член, выполняющую эту обработку:

class Widget {
public:
 …
 void process();
};

Вот вполне разумно выглядящий подход к написанию Widget::process:

void Widget::process() {
 …                                    // Обработка Widget
 processedWidgets.emplace_back(this); // Добавление в список
}                                     // обработанных Widget;
                                      // это неправильно!

Комментарий о неправильности кода относится не к использованию emplace_back, а к передаче this в качестве аргумента. (Если вы не знакомы с emplace_back, обратитесь к разделу 8.2.) Этот код будет компилироваться, но он передает обычный указатель (this) контейнеру указателей std::shared_ptr. Конструируемый таким образом указатель std::shared_ptr будет создавать новый управляющий блок для указываемого Widget (т.e. для объекта *this). Это не выглядит ужасным до тех пор, пока вы не понимаете, что, если имеются указатели std::shared_ptr вне функции-члена, которые уже указывают на этот объект Widget, вам не избежать неопределенного поведения.

API std::shared_ptr включает средство для ситуаций такого рода. Вероятно, его имя — наиболее странное среди всех имен стандартной библиотеки: std::enable_shared_from_this. Это шаблон базового класса, который вы наследуете, если хотите, чтобы класс, управляемый указателями std::shared_ptr, был способен безопасно создавать std::shared_ptr из указателя this. В нашем примере Widget будет унаследован от std::enable_shared_from_this следующим образом:

class Widget: public std::enable_shared_from {
public:
 …
 void process();

};

Как я уже говорил, std::enable_shared_from_this является шаблоном базового класса. Его параметром типа всегда является имя производного класса, так что класс Widget порождается от std::enable_shared_from_this. Если идея производного класса, порожденного от базового класса, шаблонизированного производным, вызывает у вас головную боль, попытайтесь об этом не думать. Этот код совершенно законный, а соответствующий шаблон проектирования хорошо известен, имеет стандартное имя, хотя и почти такое же странное, как