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

Для исправления ситуации надо просто обеспечить полноту типа Widget::Implв точке, где генерируется код, уничтожающий std::unique_ptr. Тип становится полным, когда его определение становится видимым, а Widget::Implопределен в файле widget.cpp. Ключом к успешной компиляции является требование, чтобы компилятор видел тело деструктора Widget(т.e. место, где компилятор будет генерировать код для уничтожения члена-данных std::unique_ptr) только внутри widget.cpp, после определения Widget::Impl.

Добиться этого просто. Объявим деструктор Widgetв widget.h, но не будем определять его там:

class Widget { // Как и ранее, в файле "widget.h"

public:

Widget();

~Widget(); // Только объявление

…

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

struct Impl;

std::unique_ptr pImpl;

};

Определим его в widget.cppпосле определения Widget::Impl:

#include "widget.h" // Как и ранее, в файле "widget.cpp"

#include "gadget.h"

#include

#include

struct Widget::Impl { // Как и ранее, определение

std::string name; // Widget::Impl

std::vector data;

Gadget g1, g2, g3;

};

Widget::Widget() // Как и ранее

: pImpl(std::make_unique()) {}

Widget::~Widget() // Определение ~Widget

{}

Это хорошо работает и требует небольшого набора текста, но если вы хотите подчеркнуть, что генерируемый компилятором деструктор работает верно, что единственная причина его объявления — генерация его определения в файле реализации Widget, то вы можете определить тело деструктора как = default:

Widget::~Widget() = default; // Тот же результат, что и выше

Классы, использующие идиому Pimpl, являются естественными кандидатами на поддержку перемещения, поскольку генерируемые компилятором операции перемещения делают именно то, что требуется: выполняют перемещение std::unique_ptr. Как поясняется в разделе 3.11, объявление деструктора Widgetпрепятствует генерации компилятором операций перемещения, так что, если вы хотите обеспечить их поддержку, вы должны объявить их самостоятельно. Поскольку генерируемые компилятором версии ведут себя так, как надо, соблазнительно реализовать их следующим образом:

class Widget { // В "widget.h"

public:

Widget();

~Widget();

Widget(Widget&& rhs) = default; // Идея верна,

Widget& operator=(Widget&& rhs) = default;// код – нет!

…

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

struct Impl;

std::unique_ptr pImpl;

};

Этот подход приводит к тем же проблемам, что и объявление класса без деструктора, и по той же самой причине. Генерируемый компилятором оператор перемещающего присваивания должен уничтожить объект, на который указывает pImpl, перед тем как присвоить указателю новое значение, но в заголовочном файле Widgetуказатель pImplуказывает на неполный тип. Ситуация отличается для перемещающего конструктора. Проблема в том, что компиляторы обычно генерируют код для уничтожения pImplв том случае, когда в перемещающем конструкторе генерируется исключение, а уничтожение pImplтребует, чтобы тип Implбыл полным.

Поскольку проблема точно такая же, как и ранее, то и решение ее такое же — перенос определений перемещающих операций в файл реализации:

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

public:

Widget();

~Widget();

Widget(Widget&& rhs); // Только объявления

Widget& operator=(Widget&& rhs);

…

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

struct Impl;

std::unique_ptr pImpl;

};

#include // В файле "widget.cpp"

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

Widget::Widget() // Как и ранее

: pImpl(std::make_unique())

{}

Widget::~Widget() = default; // Как и ранее

// Определения:

Widget::Widget(Widget&& rhs) = default;

Widget& Widget::operator=(Widget&& rhs) = default;

Идиома Pimplпредставляет собой способ снижения зависимости между реализацией класса и его клиентами, но концептуально идиома не меняет то, что представляет собой класс. Исходный класс Widgetсодержал члены-данные std::string, std::vectorи Gadget, так что в предположении, что объекты Gadget, как и объекты std::stringи std::vector, могут копироваться, имеет смысл в поддержке классом Widget копирующих операций. Мы должны написать эти функции самостоятельно, поскольку (1) компиляторы не генерируют копирующие операции для классов с типами, поддерживающими только перемещение (наподобие std::unique_ptr) и (2) даже если бы они генерировались, то такие функции выполняли бы копирование только указателя std::unique_ptr(т.e. выполняли бы мелкое копирование ), а мы хотим копировать то, на что указывает этот указатель (т.e. выполнять глубокое копирование ).

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

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