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

Тип, который был объявлен, но не определен, называется неполным типом . Widget::Implявляется таким неполным типом. С неполным типом можно сделать очень немногое, но в это немногое входит объявление указателя на него. Идиома Pimpl использует эту возможность.

Первая часть идиомы Pimpl — объявление члена-данных, который представляет собой указатель на неполный тип. Вторая часть заключается в динамическом создании и уничтожении объекта, хранящего члены-данные, использующиеся в исходном классе. Соответствующий код находится в файле реализации, например для Widget— в файле widget.cpp:

#include "widget.h" // Файл реализации "widget.cpp"

#include "gadget.h"

#include

#include

struct Widget::Impl { // Определение Widget::Impl

std::string name; // с членами-данными, ранее

std::vector data; // находившимися в Widget

Gadget g1, g2, g3;

};

Widget::Widget() // Создание членов-данных

: pimpl( new Impl) // для данного объекта Widget

{}

Widget::~Widget() // Уничтожение членов-данных

{ delete pImpl;} // для данного объекта

Здесь я привожу директивы #include, чтобы было ясно, что общие зависимости от заголовочных файлов для std::string, std::vectorи Gadgetникуда не исчезли и продолжают существовать. Однако эти зависимости перемещены из файла widget.h(видимого и используемого всеми клиентами класса Widget) в файл widget.cpp(видимый и используемый только реализацией Widget). Я также подчеркнул код динамического выделения и освобождения объекта Impl. Необходимость освобождения этого объекта при уничтожении Widgetприводит к необходимости деструктора Widget.

Но я показал код С++98, от которого пахнет пылью вековой… Нет, пылью прошлого тысячелетия. Он использует обычные указатели, обычные операторы newи delete, и вообще весь он слишком сырой [15] Непереводимая игра слов, основанная на использовании для обычного указателя названия “raw pointer” (дословно — “сырой указатель”). — Примеч. пер . . Вся текущая глава построена на идее о том, что интеллектуальные указатели куда предпочтительнее обычных указателей, и если мы хотим динамически создавать объект Widget::Implв конструкторе Widgetи должны уничтожать его вместе с Widget, то для нас отлично подойдет интеллектуальный указатель std::unique_ptr (см. раздел 4.1). Заменяя обычный указатель pImplуказателем std::unique_ptr, мы получим следующий код для заголовочного файла

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

public:

Widget();

…

private:

struct Impl;

std:unique_ptr<Impl >pImpl; // Интеллектуальный указатель

}; // вместо обычного

и для файла реализации:

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

#include "gadget.h"

#include

#include

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

std::string name;

std::vector data;

Gadget g1, g2, g3;

};

Widget::Widget() // Согласно разделу 4.4

: pImpl( std::make_unique<Impl >()) // создаем std: :unique_ptr

{} // с помощью std::make_unique

Вы заметили, что деструктора Widgetбольше нет? Дело в том, что нет никакого кода, который требуется в нем разместить. std::unique_ptrавтоматически удаляет то, на что указывает, когда он сам (указатель std::unique_ptr) уничтожается, так что нам не требуется ничего удалять вручную. Это одна из привлекательных сторон интеллектуальных указателей: они устраняют необходимость утруждать свои руки вводом кода для освобождения ресурсов вручную.

Этот код компилируется, но, увы, это не самый тривиальный клиент!

#include "widget.h"

Widget w; // Ошибка!

Получаемое вами сообщение об ошибке зависит от используемого компилятора, но в общем случае текст упоминает что-то о применении sizeofили deleteк неполному типу. Эти операции не входят в число тех, которые можно делать с такими типами.

Эта явная неспособность идиомы Pimplиспользовать std::unique_ptrвызывает тревогу, поскольку (1) указатели std::unique_ptrразрекламированы как поддерживающие неполные типы, и (2) идиома Pimpl — один из наиболее распространенных случаев применения std::unique_ptr. К счастью, этот код легко сделать работающим. Все, что для этого требуется, — понимание причины проблемы.

Проблема возникает из-за кода, который генерируется при уничтожении w(например, при выходе переменной за пределы области видимости). В этой точке вызывается ее деструктор. Если определение класса использует std::unique_ptr, мы не объявляем деструктор, так как нам нечего в него поместить. В соответствии с обычными правилами генерации специальных функций-членов компиляторами (см. раздел 3.11) этот деструктор создается вместо нас компилятором. В этот деструктор компилятор вносит код вызова деструктора члена-данных pImplкласса Widget.pImplпредставляет собой указатель std::unique_ptr, т.e. указатель std::unique_ptr, использующий удалитель по умолчанию. Удалитель по умолчанию является функцией, которая применяет оператор deleteк обычному указателю внутри std::unique_ptr. Однако перед тем как использовать delete, реализации удалителя по умолчанию в C++11 обычно применяют static_assert, чтобы убедиться, что обычный указатель не указывает на неполный тип. Когда компилятор генерирует код для деструкции Widget w, он в общем случае сталкивается с неудачным static_assert, что и приводит к выводу сообщения об ошибке. Это сообщение обычно связано с точкой, в которой происходит уничтожение w, поскольку деструктор Widget, подобно всем генерируемым компиляторами специальным функциям-членам, неявно является inline. Сообщение часто указывает на строку, в которой создается w, поскольку она представляет собой исходный текст, явно создающий объект, приводящий впоследствии к неявной деструкции.