pImpl从根本上解决C ++ DLL问题吗？ [英] Does pImpl fundamentally solve C++ DLL issue?

问题描述

我正在尝试从带有stl成员的DLL中导出C ++类。

I'm trying to export a C++ class out of a DLL with stl members.

这是我的主类。

class MATHFUNCSDLL_API MyMathFuncsImpl
    {
    public: 

       std::vector<int> vi;
      std::string getString();
      void setString(std::string s);
    private:
       std::string s;
    };

使用该方法有效，但在VS 2012上给出有关std :: string和std :: vector的警告没有DLL介面。现在，当我这样做时-

Using the methods works, but gives warnings on VS 2012 about std::string and std::vector not having a dll-interface. Now when I do this -

class  MATHFUNCSDLL_API MyMathFuncs
    {
    public:
       MyMathFuncs()
       {
          pImpl = new MyMathFuncsImpl();
       }
       std::string getString()
       {
          return pImpl->getString();
       }

       std::vector<int> getVector()
       {
          return pImpl->vi;
       }

       void setString(std::string news)
       {
          pImpl->setString(news);
       }
    private:
       MyMathFuncsImpl* pImpl;
    };

我没有收到警告，它也有效。我的问题是：具有这样的接口是否真的可以解决问题（在dll边界上实现stl成员的方式可能不同），还是抑制编译器问题的一种技巧？

I get no warnings, and it also works. My question is this: does having an interface like this really solve the problem (stl members might be implemented differently across dll boundary), or is it just a trick to suppress compiler issues?

推荐答案

是。

永远不要在DLL接口中使用内联函数。包括构造函数和析构函数，应明确声明但应在实现文件中定义。对于C ++，这意味着您应该使用pImpl习惯用法或虚拟基类。

You should never use inline functions in a DLL interface. And that includes constructors and destructors which should be explicitly declared but defined in an implementation file. For C++ that means you should use the pImpl idiom or virtual base classes.

避免内联函数的原因是，在DLL的作用下，它们可能会从一个发行版更改为另一个发行版。保持不变。任何不匹配都会导致奇怪而可怕的问题。

The reason to avoid inline functions is that they may change from one release to the next while the DLL stays the same. Any mismatch will cause weird and horrible problems.

这篇关于pImpl从根本上解决C ++ DLL问题吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！