在dll界面中使用shared_ptr [英] Using shared_ptr in dll-interfaces

问题描述

我的DLL中有一个抽象类。

I have an abstract class in my dll.

class IBase {
  protected:
       virtual ~IBase() = 0;
  public:
       virtual void f() = 0;
};

我想在我的exe中获得 IBase -file加载dll。
首先是创建以下函数

I want to get IBase in my exe-file which loads dll. First way is to create following function

IBase * CreateInterface();

并添加虚拟函数 Release（） IBase 。

第二种方法是创建另一种功能

Second way is to create another function

boost::shared_ptr<IBase> CreateInterface();

而不需要 Release（）函数

问题。

1）析构函数和内存是否正确第二种情况在dll（不在exe文件中）调用解除分配？

1) Is it true that the destructor and memory deallocation is called in the dll (not in exe-file) in the second case?

2）第二种情况<如果使用不同的编译器（或不同的设置）编译exe-file和dll，则/ em>可以正常工作。

2) Does the second case work well if exe-file and dll was compiled with different compilers (or different settings).

推荐答案

您的第一个问题的答案：您的dll中的虚拟析构函数被调用 - 其位置的信息嵌入在对象中（在vtable中）。在内存释放的情况下，它取决于您的 IBase 的用户有多严格。如果他们知道他们必须调用 Release（），并且认为该异常可以以惊人的方向绕过控制流，则将使用正确的一个。

An answer to your first question: The virtual destructor in your dll is called - the information about its location is embedded in your object (in the vtable). In the case of memory deallocation it depends how disciplined the users of your IBase are. If they know they have to call Release() and consider that exception can bypass the control flow in an surprising direction, the right one will be used.

但是如果 CreateInterface（）返回 shared_ptr< IBase> 它可以绑定右这个智能指针的释放功能正确。您的图书馆可能如下所示：

But if CreateInterface() returns shared_ptr<IBase> it can bind the right deallocation function right to this smart pointer. Your library may look like this:

Destroy(IBase* p) {
    ... // whatever is needed to delete your object in the right way    
}

boost::shared_ptr<IBase> CreateInterface() {
    IBase *p = new MyConcreteBase(...);
    ...
    return shared_ptr<IBase>(p, Destroy); // bind Destroy() to the shared_ptr
}                                         // which is called instead of a plain
                                          // delete

因此，您的DLL的每个用户都容易防止资源泄漏。他们从来不必打扰调用 Release（）或者注意异常绕过他们的控制流程。

Thus every user of your DLL is easily prevented against resource leaks. They never have to bother about calling Release() or pay attention to exceptions bypassing surprisingly their control flow.

< b>回答你的第二个问题：这个方法的缺点是被另一个答案：您的受众必须像您一样使用相同的编译器，链接器，设置和库。如果他们可以相当多，这可能是您的图书馆的主要缺点。您必须选择：安全与较大的受众

To answer your second question: The downside of this approach is clearly stated by the other answers: You're audience has to use the same compiler, linker, settings, libraries as you. And if they could be quite a lot this can be major drawback for your library. You have to choose: Safety vs. larger audience

但是有一个可能的漏洞：使用 shared_ptr< IBase> / code>在您的应用程序，即

But there's a possible loophole: Use shared_ptr<IBase>in your application, i.e.

{
    shared_ptr<IBase> p(CreateInterface(), DestroyFromLibrary);
    ...
    func();
    ...
}

因此，没有实现特定的对象跨越DLL边界。不过，您的指针安全地隐藏在 shared_ptr 之后，即使在 DestroyFromLibrary > func（）引发异常。

Thus no implementation specific object is passed across the DLL boundary. Nevertheless your pointer is safely hidden behind the shared_ptr, who's calling DestroyFromLibrary at the right time even if func()'s throwing an exception or not.

这篇关于在dll界面中使用shared_ptr的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！