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

В соответствии с ритуалом, который нам теперь хорошо знаком, мы объявляем функции в заголовочном файле и реализуем их в файле реализации:

class Widget { // В файле "widget.h"

public:

… // Прочее, как ранее

Widget(const Widget& rhs); // Только

Widget& operator=(const Widget& rhs);// объявления

private: // Как и ранее

struct Impl;

std::unique_ptr pImpl;

};

#include "widget.h" // В "widget.cpp"

…

struct Widget::Impl { … }; // Как и ранее

Widget::~Widget() = default; // Прочее, как и ранее

Widget::Widget(const Widget& rhs)// Копирующий конструктор

: pImpl(nullptr)

{ if (rhs.pImpl) pImpl = std::make_unique(*rhs.pImpl); }

// Копирующее присваивание:

Widget& Widget::operator=(const Widget& rhs) {

if (!rhs.Impl) pImpl.reset();

else if (!pImpl) pImpl = std::make_unique(*rhs.pImpl);

else *pImpl = *rhs.pImpl;

return *this;

}

Реализация достаточно проста, хотя мы и должны обрабатывать случаи, в которых параметр rhsили, в случае копирующего оператора присваивания, *thisбыл перемещен, а потому содержит нулевой указатель pImpl. В общем случае мы используем тот факт, что компиляторы создают копирующие операции для Impl, и эти операции копируют каждое поле автоматически. Так что мы реализуем копирующие операции Widgetпутем вызова копирующих операций Widget::Impl, сгенерированных компилятором. В обеих функциях обратите внимание, как мы следуем совету из раздела 4.4 предпочитать применение std::make_uniqueнепосредственной работе с new.

При реализации идиомы Pimpl используемым интеллектуальным указателем является std::unique_ptr, поскольку указатель pImplвнутри объекта (например, внутри Widget) имеет исключительное владение соответствующим объектом реализации (например, объектом Widget::Impl). Интересно также отметить, что если бы мы использовали для pImplуказатель std::shared_ptrвместо std::unique_ptr(т.e. если бы значения в структуре Implмогли совместно использоваться несколькими Widget), то нашли бы, что советы из данного раздела больше не применимы. Нам бы не потребовалось объявлять деструктор в Widget, а без пользовательского деструктора компиляторы с удовольствием генерировали бы операции перемещения, которые делали бы именно то, что от них требуется. То есть при следующем коде в файле widget.h

class Widget { // В файле "widget.h"

public:

Widget();

… // Нет объявлений деструктора

// и перемещающих операций

private:

struct Impl;

std::shared_ptr pImpl; // std::shared_ptr

}; // вместо std::unique_ptr

и приведенном далее коде клиента, который включает заголовочный файл widget.h

Widget w1;

auto w2(std::move(w1)); // Перемещающее конструирование w2

w1 = std::move(w2); // Перемещающее присваивание w1

все компилировалось бы и работало именно так, как мы рассчитывали: w1был бы создан конструктором по умолчанию, его значение было бы перемещено в w2, а затем это значение, в свою очередь, было бы перемещено в w1, после чего и w1, и w2были бы уничтожены (тем самым приводя к уничтожению объекта Widget::Impl).

Различие в поведении указателей std::unique_ptrи std::shared_ptrдля pImplвытекает из различий путей, которыми эти интеллектуальные указатели поддерживают пользовательские удалители. Для std::unique_ptrтип удалителя является частью типа интеллектуального указателя, и это позволяет компилятору генерировать меньшие структуры данных времени выполнения и более быстрый код. Следствием этой более высокой эффективности является то, что указываемые типы должны быть полными, когда используются специальные функции-члены, генерируемые компиляторами (например, деструкторы или перемещающие операции). В случае std::shared_ptrтип удалителя не является частью типа интеллектуального указателя. Это требует больших структур данных времени выполнения и несколько более медленного кода, но зато указываемые типы не обязаны быть полными при применении специальных функций-членов, генерируемых компиляторами.

При применении идиомы Pimpl в действительности нет никакого компромисса между характеристиками std::unique_ptrи std::shared_ptr, поскольку отношения между классами наподобие Widgetи Widget::Implпредставляют собой исключительное владение, и это делает единственно верным выбором в качестве инструмента интеллектуальный указатель std::unique_ptr. Тем не менее стоит знать, что в других ситуациях — ситуациях, в которых осуществляется совместное владение (а следовательно, правильным выбором является std::shared_ptr), — нет необходимости прыгать через горящие обручи определений функций, которую влечет за собой применение std::unique_ptr.