Проектирование создания и уничтожения класса с использованием идиомы pimpl

Теперь это почти вопрос проверки кода, поэтому вы можете рассмотреть возможность размещения его на CodeReview.SE. Кроме того, это может не соответствовать философии StackOverflow: конкретные вопросы с конкретными ответами, без обсуждения. Тем не менее попробую представить альтернативу.

Анализ и критика (подробностей) подхода ОП

Entry(EntryImpl* impl) : m_Impl(impl) { }
// 2. Public destructor
~Entry() { delete m_Impl; }

Как уже говорилось в ОП, ни одна из этих функций не должна вызываться пользователем библиотеки. Деструктор вызывает Undefined Behavior, например, если EntryImpl имеет нетривиальный деструктор.

На мой взгляд, нет особой пользы в том, чтобы запретить пользователям создавать новые объекты Entry. В одном из предыдущих подходов OP все конструкторы Entry были закрытыми. С текущим решением OP пользователь библиотеки может написать:

Entry e(0);

Что создает объект e, который нельзя разумно использовать. Обратите внимание, что Entry не должен быть копируемым, так как он владеет объектом, на который указывает указатель члена данных.

Однако, независимо от определения класса Entry, пользователь библиотеки всегда может создать объект, который ссылается на любой объект Entry, используя указатель. (Это аргумент против оригинальной реализации, которая возвращала Entry& из дерева.)

Насколько я понимаю намерения OP, объект Entry использует указатель для «расширения» своего собственного хранилища до некоторой фиксированной памяти в куче:

class Entry final
{
private:
    EntryImpl* const m_Impl;

Поскольку это const, вы не можете переустановить указатель. Между Entry объектами и EntryImpl объектами существует связь 1-к-1. Однако интерфейс библиотеки обязательно имеет дело с EntryImpl указателями. Это то, что по существу передается от реализации библиотеки пользователю библиотеки. Сам класс Entry, по-видимому, служит только для установления связи 1-к-1 между объектами Entry и EntryImpl.

Мне до сих пор не совсем ясно, какова связь между Entrys и Trees. Кажется, что каждый Entry должен принадлежать Tree, что означает, что объект Tree должен владеть всеми созданными из него записями. Это, в свою очередь, подразумевает, что все, что пользователь библиотеки получает от Tree::AddEntry, должно быть представлением записи, принадлежащей дереву, то есть указателем. В этом свете вы должны рассмотреть решение ниже.

Подход с использованием полиморфизма

Этот подход работает (только), если вы можете совместно использовать виртуальную таблицу между реализацией библиотеки и пользователем библиотеки. Если это не так, вы можете реализовать аналогичный подход, используя непрозрачный указатель вместо интерфейса с виртуальными функциями. Это даже позволяет определить интерфейс библиотеки как C API (см. интерфейсы песочных часов для C++ API).

Рассмотрим классическое решение требований:

// interface headers:

class IEntry // replacement for `Entry`
{
public:
    // public API as virtual functions
};

class Tree
{
    // [implementation]
public:
    IEntry* AddEntry();
    void DoSomething();
};


// implementation headers:

class EntryImpl : public IEntry
{
    // implementation
};

// implementation of `Tree::AddEntry` returns an `EntryImpl*`

Это решение полезно, если дескриптор записи (IEntry*) не владеет записью, на которую он ссылается. Путем приведения от IEntry* к EntryImpl* библиотека может взаимодействовать с более закрытыми частями записи. Может быть даже второй интерфейс для библиотеки, который отделяет EntryImpl от Tree. Насколько я понимаю, для такого подхода не требуется никакой дружбы между классами.

Обратите внимание, что несколько лучшим решением может быть позволить классу EntryImpl реализовать концепцию, а не интерфейс, и обернуть EntryImpl объекты в адаптер, реализующий виртуальные функции. Это позволяет повторно использовать класс EntryImpl для другого интерфейса.

В приведенном выше решении пользователь библиотеки имеет дело с указателем:

Tree myTree;
auto myEntry = myTree.AddEntry();
myEntry->SomeFunction();

Чтобы задокументировать, что этот указатель не владеет объектом, на который он указывает, вы можете использовать то, что было названо «самым тупым умным указателем в мире». По сути, это легкая оболочка необработанного указателя, который как тип выражает, что он не владеет объектом, на который указывает:

class Tree
{
    // [implementation]
public:
    non_owning_pointer<IEntry> AddEntry();
    void DoSomething();
};

Если вы хотите разрешить пользователю удалять записи, вы должны удалить их из своего дерева. В противном случае вам придется иметь дело с уничтоженными записями явно, например. в TreeImpl::DoSomething. На данный момент мы начинаем перестраивать систему управления ресурсами для записей; первым шагом которого обычно является разрушение. Однако у пользователя библиотеки могут быть различные требования к сроку жизни своих записей. Если вы просто возвращаете shared_ptr, это может быть ненужным накладным расходом; если вы вернете unique_ptr, пользователю библиотеки, возможно, придется обернуть это unique_ptr в shared_ptr. Даже если эти решения не сильно влияют на производительность, я бы посчитал их странными с концептуальной точки зрения.

Следовательно, я бы сказал, что для интерфейса следует придерживаться наиболее общего способа управления сроком службы, который (насколько мне известно) похож на комбинацию ручного "нового" и "удалить" вызовы. Мы не можем использовать эти возможности языка напрямую, так как они также имеют дело с памятью.

Удаление записи из ее дерева требует знания как записи, так и дерева. То есть либо вы предоставляете обе функции для уничтожения, либо сохраняете указатель дерева в каждой записи. Другой способ взглянуть на это так: если вам уже нужен TreeImpl* в EntryImpl, вы получите его бесплатно. С другой стороны, пользователь библиотеки может уже иметь Tree* каждой записи.

class Tree
{
    // [implementation]
public:
    non_owning_pointer<IEntry> AddEntry();
    void RemoveEntry(non_owning_pointer<IEntry>);

    void DoSomething();
};

_{(После того, как я это написал, это напомнило мне об итераторах, хотя они также позволяют перейти к следующей записи.)}

С помощью этого интерфейса вы можете легко написать unique_ptr<IEntry, ..> и shared_ptr<IEntry>. Например:

namespace detail
{
    class UnqiueEntryPtr_deleter {
        non_owning_pointer<Tree> owner;
    public:
        UnqiueEntryPtr_deleter(Tree* t) : owner{t} ()
        void operator()(IEntry* p) { owner->RemoveEntry(p); }
    };
}

using unique_entry_ptr = std::unique_ptr<IEntry, UniqueEntryPtr_deleter>;

auto AddEntry(Tree& t) // convenience function
{ return unique_entry_ptr{ t.AddEntry(), &t }; }

Точно так же вы можете создать объект, который содержит unique_ptr для записи и shared_ptr для ее владельца Tree. Это предотвращает проблемы со сроком службы Entry*, которые относятся к мертвым деревьям.

Поднятие абстракции в подходах PIMPL

Конечно, использование полиморфизма позволяет легко перейти от IEntry* к EntryImpl* внутри библиотеки. Можем ли мы решить проблему также для подхода PIMPL? Да, либо через дружбу (как в OP), либо через функцию, которая извлекает (копию) PIMPL:

class EntryImpl;
class Entry
{
    EntryImpl* pimpl;
public:
    EntryImpl const* get_pimpl() const;
    EntryImpl* get_pimpl();
};

Это выглядит не очень красиво, но необходимо, чтобы части библиотеки, скомпилированные пользователем, извлекали этот указатель (например, пользовательский компилятор может выбрать другую структуру памяти для объектов Entry). Пока EntryImpl является непрозрачным указателем, можно утверждать, что инкапсуляция Entry не нарушается. Фактически, EntryImpl может быть хорошо инкапсулирован.