我有一个STL对象的应用程序,用作插件编写器的C++接口的一部分.
我知道兼容性的最佳选择是使用C接口,但目前不可行.
我知道libstdc ++中从GCC 3.4到4.8的所有内容在ABI方面都是高度兼容的.
因此,例如,如果我使用GCC 4.1进行编译,并且插件供应商编写使用GCC 4.7编译的代码,那么禁止角落情况一切都将在具有与GCC 4.7或更高版本相对应的libstdc ++版本的平台上完成,前提是STL用法是只有.so的内部,以及外部的.so界面使用的是纯粹的C,但对我来说情况并非如此.
所以,我很好奇关于作为插件接口的一部分使用的STL类的情况.我可以安全地在未使用相同编译器版本编译的共享对象之间传递STL对象(例如4.1和4.8)吗？如果人们使用不同的编译器选项,是否有任何关于如何编译和解决模板的问题需要注意什么？
我怀疑它会有问题.然而,GCC人员有可能以某种方式完成这项工作.
对于这个问题,我只对pre-C++ 11编译和链接感兴趣.我也只对使用GCC的Linux和Mac OS X感兴趣.
众所周知，堆内存的释放必须使用与分配它的分配器相同的分配器来完成。在跨 DLL 边界交换堆分配的对象时需要考虑这一点。
一种解决方案是为每个对象提供一个析构函数，就像在 C API 中一样：如果 DLL 允许创建对象 A，则它必须提供一个函数A_free或类似的东西1。
另一个相关的解决方案是将所有分配包装到其中，因为它们存储到释放器2shared_ptr的链接。
另一种解决方案是将顶级分配器“注入”到所有加载的 DLL（递归地）3中。
另一种解决方案是不交换堆分配的对象，而是使用某种协议4。
另一种解决方案是绝对确保 DLL 将共享相同的堆，如果它们共享兼容的编译选项（编译器、标志、运行时等），则应该（将会？）发生这种情况5 6。这似乎很难保证，特别是如果人们想使用包管理器而不是立即构建所有内容。
有没有办法在运行时检查多个 DLL 之间的堆实际上是否相同，最好以跨平台的方式？
为了可靠性和易于调试，这似乎比希望应用程序立即崩溃而不是默默地破坏东西更好。