带STL类型的纯抽象类能否作为DLL接口？相关使用疑问

我是一名DLL库开发初学者，了解过ABI兼容性，但不确定纯抽象类是否可以包含带有STL返回类型或参数的函数。以下是相关代码示例：

DLL中的代码 #

foo.h #

class IFoo {
public:
    virtual void Hello(const std::string&) = 0; // 该声明是否可行？
};

__declspec(dllexport) void Inject(IFoo& foo);

foo.cc #

IFoo* g_foo;

void Inject(IFoo& foo) {
    g_foo = &foo;
}

应用程序中的代码 #

class Foo : public IFoo {
public:
    void Hello(const std::string& msg) override {
        // 实现逻辑
    }
};

Foo foo;
Inject(foo);

请问使用*g_foo是否会存在问题？

解答 #

1. 关于IFoo::Hello声明的可行性
   这个声明在特定条件下可行，但存在严重的ABI兼容性风险：

• STL容器（比如std::string）的内存布局、内部实现细节会随编译器版本、编译选项（如Debug/Release、是否启用STL调试模式）、甚至STL标准库的实现（如MSVC的STL vs GCC的libstdc++）而变化。
• 如果DLL和应用程序使用的编译器/版本/编译选项不一致，std::string的ABI会不兼容，调用Hello函数时会出现内存访问错误、崩溃等问题。

2. 关于使用*g_foo的问题
   如果满足以下条件，使用*g_foo调用成员函数是安全的：

• DLL和应用程序对IFoo的定义完全一致（虚函数的数量、顺序、签名都无差异）
• 双方使用的编译器、版本、编译选项完全匹配，确保std::string的ABI兼容

但只要STL的ABI不匹配，哪怕虚函数表的布局是正确的，Hello函数的参数传递（const std::string&）也会因为内存结构不一致导致错误。

注意事项 #

• 跨DLL接口尽量避免直接使用STL类型，替代方案可以是C风格字符串（const char*）、自定义轻量字符串类，或者严格约定双方的编译环境完全一致。
• 纯抽象类作为DLL接口时，必须保证所有虚函数的签名在DLL和应用程序中完全同步，任何修改都需要重新编译双方代码。

内容的提问来源于stack exchange，提问作者imja