这正在成为我的代码中的一种常见模式,因为当我需要管理一个需要不可复制的对象时,因为 A. 它是“重”或 B. 它是操作系统资源,例如关键部分:
class Resource;
class Implementation : public boost::noncopyable
{
friend class Resource;
HANDLE someData;
Implementation(HANDLE input) : someData(input) {};
void SomeMethodThatActsOnHandle() {
//Do stuff
};
public:
~Implementation() { FreeHandle(someData) };
};
class Resource
{
boost::shared_ptr<Implementation> impl;
public:
Resource(int argA) explicit {
HANDLE handle =
SomeLegacyCApiThatMakesSomething(argA);
if (handle == INVALID_HANDLE_VALUE)
throw SomeTypeOfException();
impl.reset(new Implementation(handle));
};
void SomeMethodThatActsOnTheResource() {
impl->SomeMethodThatActsOnTheHandle();
};
};
这样,shared_ptr 解决了引用计数问题,允许Resource
复制,即使底层句柄只有在所有对它的引用都被销毁后才应该关闭。
Implementation
但是,如果我们可以像 boost 的侵入式容器那样将数据移动到内部,似乎我们可以节省分配 shared_ptr 引用计数等的开销。
如果这让过早的优化问题困扰了一些人,我实际上同意我当前的项目不需要这个。但我很好奇这是否可能。