Std :: auto_ptr или boost :: shared_ptr для идиомы pImpl?

Не пытайся так сильно прострелить себе ногу, в C++ у тебя масса возможностей :) Нет никакой реальной необходимости использовать автоматические указатели, поскольку вы прекрасно знаете, когда ваш объект должен входить и выходить из жизни (в вашем конструкторе (ах) и деструкторе).

Будь проще.

Я обычно использую auto_ptr. Обязательно сделайте свой класс не копируемым (объявите частную копию ctor & operator =, иначе унаследуйте boost::noncopyable). Если вы используете auto_ptr, одна проблема заключается в том, что вам нужно определить не встроенный деструктор, даже если тело пусто. (Это потому, что если вы позволите компилятору сгенерировать деструктор по умолчанию, impl будет неполным типом при генерации вызова delete impl_, вызывая неопределенное поведение).

Выбирать между auto_ptr и указателями ускорения практически некуда. Я стараюсь не использовать boost по стилистическим соображениям, если подойдет стандартная альтернатива библиотеки.

Альтернативой std::auto_ptr является boost::scoped_ptr. Основное отличие от auto_ptr в том, что boost::scoped_ptr нельзя копировать.

Подробнее см. эта страница.

Если вы действительно педантичны, нет абсолютной гарантии, что использование члена auto_ptr не требует полного определения параметра шаблона auto_ptr в той точке, в которой он используется. Сказав это, я никогда не видел, чтобы это не работало.

Один из вариантов - использовать const auto_ptr. Это работает до тех пор, пока вы можете создать свой 'pimpl' с новым выражением внутри списка инициализаторов, и гарантирует, что компилятор не могу сгенерирует конструктор копирования по умолчанию и методы присваивания. По-прежнему необходимо предоставить не встроенный деструктор для включающего класса.

При прочих равных, я бы предпочел реализацию, которая использует только стандартные библиотеки, поскольку она делает вещи более переносимыми.

Вам не стоит использовать для этого std :: auto_ptr. Деструктор не будет виден в момент объявления std :: auto_ptr, поэтому он может быть вызван неправильно. Предполагается, что вы заранее объявляете свой класс pImpl и создаете экземпляр внутри конструктора в другом файле.

Если вы используете boost :: scoped_ptr (здесь нет необходимости в shared_ptr, вы не будете использовать pimpl совместно с любыми другими объектами, и это обеспечивается тем, что scoped_ptr является не копируемый), вам нужен только деструктор pimpl, видимый в точке, где вы вызываете конструктор scoped_ptr.

Например.

// in MyClass.h

class Pimpl;

class MyClass 
{ 
private:
    std::auto_ptr<Pimpl> pimpl;

public: 
    MyClass();
};

// Body of these functions in MyClass.cpp

Здесь компилятор сгенерирует деструктор MyClass. Которая должна вызывать деструктор auto_ptr. В момент создания деструктора auto_ptr Pimpl является неполным типом. Таким образом, в деструкторе auto_ptr, когда он удаляет объект Pimpl, он не знает, как вызвать деструктор Pimpl.

boost :: scoped_ptr (и shared_ptr) не имеют этой проблемы, потому что, когда вы вызываете конструктор scoped_ptr (или метод сброса), он также создает эквивалент указателя на функцию, который он будет использовать вместо вызова delete. Ключевым моментом здесь является то, что он создает экземпляр функции освобождения, когда Pimpl не является неполным типом. В качестве побочного примечания, shared_ptr позволяет вам указать функцию настраиваемое освобождение, поэтому вы можете использовать ее для таких вещей, как ручки GDI или что-то еще, что вы можете захотеть, но здесь это излишне для ваших нужд.

Если вы действительно хотите использовать std :: auto_ptr, вам нужно проявить особую осторожность, убедившись, что вы определяете деструктор MyClass в MyClass.cpp, когда Pimpl полностью определен.

// in MyClass.h

class Pimpl;

class MyClass 
{ 
private:
    std::auto_ptr<Pimpl> pimpl;

public: 
    MyClass();
    ~MyClass();
};

и

// in MyClass.cpp

#include "Pimpl.h"

MyClass::MyClass() : pimpl(new Pimpl(blah))
{
}

MyClass::~MyClass() 
{
    // this needs to be here, even when empty
}

Компилятор сгенерирует код, который эффективно уничтожит все члены MyClass «в» пустом деструкторе. Итак, в момент создания деструктора auto_ptr Pimpl больше не является неполным, и теперь компилятор знает, как вызвать деструктор.

Лично я не думаю, что стоит тратить время на то, чтобы убедиться, что все правильно. Также существует риск, что кто-то придет позже и приведёт в порядок код, удалив кажущийся избыточным деструктор. Так что для такого рода вещей безопаснее использовать boost :: scoped_ptr.

boost :: shared_ptr специально разработан для работы с идиомой pimpl. Одним из основных преимуществ является то, что он позволяет не определять деструктор для класса, содержащего pimpl. Политика совместного владения может быть как преимуществом, так и недостатком. Но в более позднем случае вы можете правильно определить конструктор копирования.

shared_ptr намного предпочтительнее auto_ptr для pImpl, потому что ваш внешний класс может внезапно потерять свой указатель при его копировании.

С shared_ptr вы можете использовать объявленный вперед тип, чтобы он работал. auto_ptr не допускает заранее объявленного типа. Как и scoped_ptr, и если ваш внешний класс в любом случае не будет копируемым и имеет только один указатель, он также может быть обычным.

Можно много сказать об использовании навязчивого счетчика ссылок в pImpl и о том, чтобы внешний класс вызвал его копию и назначил семантику в ее реализации. Предполагая, что это истинная модель поставщика (предоставляет класс), лучше, чтобы поставщик не заставлял пользователя использовать shared_ptr или использовать ту же версию shared_ptr (boost или std).

Если вам нужен копируемый класс, используйте scoped_ptr, который запрещает копирование, что затрудняет неправильное использование вашего класса по умолчанию (по сравнению с использованием shared_ptr, компилятор не будет генерировать средства копирования самостоятельно; а в случае shared_ptr, если вы не знаю, что вы делаете (что достаточно часто бывает даже для мастеров), может возникнуть странное поведение, когда вдруг копия чего-то также модифицирует это что-то), а затем переопределить конструктор копирования и присваивание копии:

class CopyableFoo {
public:
    ...
    CopyableFoo (const CopyableFoo&);
    CopyableFoo& operator= (const CopyableFoo&);
private:
    scoped_ptr<Impl> impl_;
};

...
CopyableFoo (const CopyableFoo& rhs)
    : impl_(new Impl (*rhs.impl_))
{}

Я был очень доволен impl_ptr Владимира Батова [изменено]. Это упрощает создание pImpl без необходимости явно указывать конструктор копирования и оператор присваивания.

Я изменил исходный код, так что теперь он похож на shared_ptr, поэтому его можно использовать в коде эпилога, и он остается быстрым.