在使用pImpl惯用法时，是否优先使用boost::shared_ptr而不是std::auto_ptr? 我记得曾经读到过boost版本更加友好于异常处理？
class Foo
{
public:
Foo();
private:
struct impl;
std::auto_ptr<impl> impl_;
};
class Foo
{
public:
Foo();
private:
struct impl;
boost::shared_ptr<impl> impl_;
};
[编辑] 是否总是安全使用std::auto_ptr<>，或者是否存在需要另一种替代的boost智能指针的情况？
您不应该真正使用std::auto_ptr来做这件事。在您声明std::auto_ptr时，析构函数可能不可见，因此可能无法正确调用。这是假设您正在前向声明pImpl类，并在另一个文件的构造函数中创建实例。
如果您使用boost::scoped_ptr（这里不需要shared_ptr，您不会与任何其他对象共享pimpl，并且这是通过scoped_ptr为noncopyable而强制执行的），则只需要在调用scoped_ptr构造函数时使pimpl析构函数可见。
例如：
// 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的构造函数（或reset方法）时，它也会创建一个函数指针等效物，它将用来代替调用delete。关键点在于，在Pimpl不是未完成类型时，它会实例化释放函数。顺便说一句，shared_ptr允许您指定自定义回收函数，因此您可以将其用于GDI句柄之类的东西 - 但这对您在此处的需求来说过于繁琐。
如果您确实想使用std::auto_ptr，则需要特别小心，确保您在Pimpl完全定义时在MyClass.cpp中定义MyClass析构函数。
// 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
}
boost::scoped_ptr 不像 shared_ptr 那样在构造时使用类型擦除来捕获删除器，std::unique_ptr 也是如此。它们两个与 std::auto_ptr 相同，存在关于不完全类型的问题。请参见 scoped_ptr 和 GOTW 100。 - Andrew Durward我倾向于使用 auto_ptr。请确保将您的类设置为不可复制（声明私有复制构造函数和运算符=，或者继承 boost::noncopyable）。如果使用 auto_ptr，一个需要注意的问题是，即使空体，也需要定义非内联析构函数。（这是因为如果让编译器生成默认析构函数，在生成调用 delete impl_ 时，impl 将是不完整的类型，从而导致未定义的行为）。
在 auto_ptr 和 boost 指针之间几乎没有什么区别。如果标准库提供的替代品可以胜任，出于风格上的考虑，我倾向于不使用 boost。
auto_ptr 应该是可移动的，而 scoped_ptr 不是。你提供的文档也提到了这一点：“使用 scoped_ptr 而不是 auto_ptr 的主要原因是让代码读者知道你打算仅将“资源获取即初始化”应用于当前作用域，并且没有意图转移所有权。” - Sebastian Machboost::shared_ptr是专门为pimpl惯用法量身定制的。其中一个主要优点是允许不为持有pimpl的类定义析构函数。共享所有权策略既可能是优势也可能是劣势。但在后一种情况下，您可以适当地定义拷贝构造函数。
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_))
{}
CopyableFoo旨在可复制。使用scoped_ptr<>可以确保您不会忘记编写复制分配和构造函数。因为scoped_ptr<>本身不可复制，所以编译器不会尝试自动发出它们。如果您使用shared_ptr<>，编译器将发出可能不符合您意图的复制操作。请记住，我的类旨在可复制，而不是不可复制。当然，您是正确的，应该使用boost::noncopyable来实现这一点。 - Sebastian Mach如果你非常严谨，使用auto_ptr成员并不能绝对保证在使用时不需要auto_ptr的模板参数的完整定义。尽管如此，我从未见过这种情况失败。
一种变化是使用const auto_ptr。只要您可以在初始化列表中使用new表达式构造您的“pimpl”，就可以保证编译器无法生成默认的复制构造函数和赋值方法。仍然需要提供封闭类的非内联析构函数。
其他条件相同的情况下，我更喜欢使用仅使用标准库的实现，因为它使事情更具可移植性。
对于pImpl，shared_ptr比auto_ptr更可取，因为当你复制它时，外部类可能会突然丢失其指针。
使用shared_ptr时，你可以使用前向声明类型，这样就能正常工作。auto_ptr不允许前向声明类型。scoped_ptr也不允许，如果你的外部类无论如何都不可复制，并且只有一个指针，那么它最好是一个常规指针。
在pImpl中使用侵入式引用计数有很多好处，让外部类在其实现中调用其复制和赋值语义。假设这是一个真实的供应商（提供类）模型，最好是供应商不强迫用户使用shared_ptr，也不强迫用户使用相同版本的shared_ptr（boost或std）。
我非常喜欢 Vladimir Batov 改进版的 impl_ptr。它使得创建一个 pImpl 变得非常容易，而不需要显式地复制构造函数和赋值运算符。
我修改了原始代码，现在它类似于 shared_ptr，因此可以在尾声代码中使用，并保持高速运行。
不要试图在C++中自己给自己找麻烦，因为你有很多机会 :) 既然你完全知道对象何时应该进入和退出生命周期（在构造函数和析构函数中），所以没有真正的必要使用auto指针。
保持简单。
scoped_ptr、shared_ptr、auto_ptr或其他），而你的“shell”类仅仅是将调用转发到实现类并在其析构函数中删除指针。不知怎么的，如果shell类做了更多的事情，那么设计可能会出问题。 - Gregory Pakosz