追踪 shared_ptr 的所有者?
Tracking down owner of a shared_ptr?
在我们的应用程序中,我们即将(最终..)从原始指针切换到使用 C++11 smart_ptr
模板。
我们的应用程序中确实存在偶尔的错误,(非 C++)对象仍然保留对我们的 C++ 对象的引用,导致过去在访问 then-dealloc'd 对象时崩溃。
不确定这是否是一个愚蠢的问题 - 但有没有办法利用 smart_ptr
对象和“转储”对象仍然坚持none 时的 C++ 对象是否需要再持有一个引用?
我想我要的是一种在特定时间点列出 smart_ptr<MyClass>
的所有所有者的方法。
非常感谢任何建议!
不要相信这对于任何开箱即用的 c++ 智能指针都是可能的。你可以简单地包装一个 shared_ptr 来达到同样的效果。
template<typename T>
class mySmartPtr : boost::noncopyable{
public:
// This method should be the only way this object can be copied
// as the copy constructors are made private
// The newOwnerName parameter can be used to populate m_onwers.
static mySmartPtr<T> newOwner(mySmartPtr<T>&, std::string newOnwerName);
private:
std::shared_ptr<T> m_ptr;
static std::vector<std::string> m_owners;
};
没有。如果不创建自己的智能指针 类 来包装 std::unique_ptr
和 std::shared_ptr
(忽略已弃用的 std::auto_ptr
)来跟踪此信息,则无法做到这一点。
标准 类 本身不跟踪此信息(成本太高)。
另一种选择是修改标准库实现的代码以跟踪该信息。对 您的 代码的侵入性较小,因为您可以继续使用标准名称。但可能比仅包装 类 并使用包装器更棘手。
We do have the occasional bug in our app with (non C++) objects still keeping references to our C++ objects causing crashes in the past when accessing the then-dealloc'd objects.
这件事很严重,不容忽视。
如果您在您的对象上给予第 3 方库组件观察者状态,那么第 3 方组件的观察者不能比您的对象长寿是理所当然的。
此问题有 3 个常见原因:
第三方组件的生命周期管理不当(你在关闭第三方观察者之前删除了被观察的对象)
未正确检测交叉案例(导致上述 1)
在您是组件的情况下,您必须接受第 3 方框架的命令,决定何时可以处置您的对象。
在涉及 shared_ptr
之前,您应该首先证明 shared_ptr 可以合法地销毁该对象。如果 3rd 方组件有一个 'deregister' 方法,那么你可以通过以下方式解决这个问题:
- 确保第 3 方组件的所有权和您观察到的对象由相同的 shared_ptr 或
控制
- 在 shared_ptr 上使用自定义删除器在最终删除之前在第 3 方对象上取消注册受控对象。
如果 none 清楚这一点,那么是时候好好看看你的对象生命周期了。经常画时序图有帮助
在我们的应用程序中,我们即将(最终..)从原始指针切换到使用 C++11 smart_ptr
模板。
我们的应用程序中确实存在偶尔的错误,(非 C++)对象仍然保留对我们的 C++ 对象的引用,导致过去在访问 then-dealloc'd 对象时崩溃。
不确定这是否是一个愚蠢的问题 - 但有没有办法利用 smart_ptr
对象和“转储”对象仍然坚持none 时的 C++ 对象是否需要再持有一个引用?
我想我要的是一种在特定时间点列出 smart_ptr<MyClass>
的所有所有者的方法。
非常感谢任何建议!
不要相信这对于任何开箱即用的 c++ 智能指针都是可能的。你可以简单地包装一个 shared_ptr 来达到同样的效果。
template<typename T>
class mySmartPtr : boost::noncopyable{
public:
// This method should be the only way this object can be copied
// as the copy constructors are made private
// The newOwnerName parameter can be used to populate m_onwers.
static mySmartPtr<T> newOwner(mySmartPtr<T>&, std::string newOnwerName);
private:
std::shared_ptr<T> m_ptr;
static std::vector<std::string> m_owners;
};
没有。如果不创建自己的智能指针 类 来包装 std::unique_ptr
和 std::shared_ptr
(忽略已弃用的 std::auto_ptr
)来跟踪此信息,则无法做到这一点。
标准 类 本身不跟踪此信息(成本太高)。
另一种选择是修改标准库实现的代码以跟踪该信息。对 您的 代码的侵入性较小,因为您可以继续使用标准名称。但可能比仅包装 类 并使用包装器更棘手。
We do have the occasional bug in our app with (non C++) objects still keeping references to our C++ objects causing crashes in the past when accessing the then-dealloc'd objects.
这件事很严重,不容忽视。
如果您在您的对象上给予第 3 方库组件观察者状态,那么第 3 方组件的观察者不能比您的对象长寿是理所当然的。
此问题有 3 个常见原因:
第三方组件的生命周期管理不当(你在关闭第三方观察者之前删除了被观察的对象)
未正确检测交叉案例(导致上述 1)
在您是组件的情况下,您必须接受第 3 方框架的命令,决定何时可以处置您的对象。
在涉及 shared_ptr
之前,您应该首先证明 shared_ptr 可以合法地销毁该对象。如果 3rd 方组件有一个 'deregister' 方法,那么你可以通过以下方式解决这个问题:
- 确保第 3 方组件的所有权和您观察到的对象由相同的 shared_ptr 或 控制
- 在 shared_ptr 上使用自定义删除器在最终删除之前在第 3 方对象上取消注册受控对象。
如果 none 清楚这一点,那么是时候好好看看你的对象生命周期了。经常画时序图有帮助