在模块（exe 和 dll）之间使用 STL（TR1）shared_ptr 是否安全

发布于 2024-07-09 17:01:07 字数 502 浏览 4 评论 0原文

我知道在一个模块中新建某些内容并在另一个模块中删除它通常会导致 VC++ 中出现问题。不同运行时的问题。如果我没记错的话，将模块与静态链接的运行时和/或动态链接的版本控制不匹配混合在一起都会搞砸。

但是，跨模块使用 VC++ 2008 的 std::tr1::shared_ptr 安全吗？

由于只有一个版本的运行时知道共享指针是什么，静态链接是我唯一的危险（目前...）。我以为我已经读到了 boost 版本的 shared_ptr 可以安全地使用，但我正在使用 Redmond 的版本......

我试图避免对分配模块中的自由对象进行特殊调用。（或者类似类本身中的“删除这个”）。如果这一切看起来有点古怪，我将使用它进行单元测试。如果您曾经尝试过对现有 C++ 代码进行单元测试，您就会明白您有时需要多么创造力。我的内存是由 EXE 分配的，但最终将在 DLL 中释放（如果引用计数按照我认为的方式工作）。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

清醇 2024-07-16 17:01:08

我在一般主题上看到的最好建议是，内存应该在分配的同一上下文中释放。但这并不排除库传回应用程序代码应该释放的指针，因此我想说您以这种方式传递共享指针可能是安全的，因为这是相同的一般情况。

如果系统的语义意味着指针实际上从 exe 转移（在所有权意义上）到 dll，那么 auto_ptr 可能是更好的解决方案。但是，如果您的指针确实是共享的，那么shared_ptr可能是最好的解决方案。

回复收藏 0 原文

夏雨凉 2024-07-16 17:01:07

释放内存是安全的，只要它们都来自相同的内存管理上下文。您已经确定了最常见的问题（不同的 C++ 运行时）；拥有单独的堆是您可能遇到的另一个不太常见的问题。

另一个你没有提到的问题，但共享指针可能会加剧这个问题，那就是当一个对象的代码存在于 DLL 中并由 DLL 创建时，但 DLL 外部的另一个对象最终引用了它（通过共享指针）。指针）。如果该对象在 DLL 卸载后被销毁（例如，如果它是模块级静态，或者通过 FreeLibrary() 显式卸载 DLL，则共享对象的析构函数将崩溃。

这可以如果您尝试编写基于 DLL 的松散耦合插件，那就麻烦了。这也是 COM 让 DLL 决定何时卸载它们，而不是让 COM 服务器按需卸载它们的原因。

回复收藏 0 原文

各空 2024-07-16 17:01:07

您开始看到 shared_ptr 是多么令人难以置信:)

跨越 DLL 边界的安全正是 shared_ptr 的设计初衷（当然，还有其他一些事情）。

与其他人所说的相反，在构造 shared_ptr 时，您甚至不需要传递自定义删除器，因为默认值已经类似于

template <typename T>
struct default_deleter {
    void operator()( T * t ) { delete t; }
};

并且

shared_ptr<Foo> foo( new Bar );

相当于

shared_ptr<Foo> foo( new Bar, default_deleter<Bar>() );

（即，不存在诸如shared_ptr 没有删除器）。

由于删除器上执行了类型擦除，所调用的delete将始终来自于实例化shared_ptr的DLL。，绝不是 DLL 中最后一个 shared_ptr 超出范围的那个（即，调用删除器的 shared_ptr 将通过指向函数的指针来调用它）由原始的 shared_ptr 放在那里）。

将此与 auto_ptr 进行比较，后者将 delete 运算符直接嵌入到其（内联）析构函数中，这意味着 delete DLL destroys使用了auto_ptr，产生了与删除裸指针相同的问题。

通过相同的技术，始终保存在 shared_ptr 中的多态类甚至不需要虚拟析构函数，因为删除器将始终调用正确的析构函数，即使最后一个 shared_ptr code> 超出范围是为基类实例化的。

You're beginning to see how incredibly amazing shared_ptr is :)

Being safe across DLL boundaries is exactly what shared_ptr was designed to be (among other things, of course).

Contrary to what others have said, you don't even need to pass a custom deleter when constructing the shared_ptr, as the default is already something like

template <typename T>
struct default_deleter {
    void operator()( T * t ) { delete t; }
};

and

shared_ptr<Foo> foo( new Bar );

is equivalent to

shared_ptr<Foo> foo( new Bar, default_deleter<Bar>() );

(ie. there's no such thing as a shared_ptr without a deleter).

Because of the type erasure performed on the deleter, the delete that's called will always be the one from the DLL that instantiated the shared_ptr, never the one from the DLL where the last shared_ptr goes out of scope (ie. the shared_ptr invoking the deleter will call it through a pointer to a function put there by the original shared_ptr).

Compare this to auto_ptr, which embeds the delete operator directly in its (inline) destructor, which means that the delete of the DLL that destroys the auto_ptr is used, creating the same problems as deleting a naked pointer.

By the same technique, polymorphic classes that are always held in shared_ptrs don't even need a virtual destructor, because the deleter will always call the right destructor, even when the last shared_ptr to go out of scope is one instantiated for the base class.

回复收藏 0 原文