为什么我应该用c ++而不是c来设置插件接口
由于我之前的 问题，我问自己：为插件系统设置C ++接口是否有用？ 以下几点是针对它的：
- 不同编译器及其版本之间没有共同的ABI，内存中没有对象的共同布局
- 没有直接的类出口。 你必须出口工厂和析构工具。 如果您的对象由仅
delete它们的其他对象（例如智能指针）保持，则会出现问题。 - STL的不同实现，你不能将
std::list传递给插件 - Boost使用的库的不同版本
如果你克制自己的C ++语言的其余部分，你几乎最终得到“C子集”。 有没有关于使用C ++的观点？ Qt-Toolkit如何解决上述问题？
备注：我主要指的是Linux系统。 不过我对其他平台上的解决方案感兴趣。
其他问题：使用C接口有什么问题？ struct s的内存布局？ 应该避免C的哪些语言部分？
虽然这更多是关于“如何”而不是“为什么”，但您可能对（尚未）Boost.Extension库以及作者关于该主题的博客感兴趣。
对于“为什么”部分，我的2（加拿大）美分：它取决于受众（插件编写者）以及应用程序与其插件之间的接口的丰富程度：
- 如果受众是大型或异构的，C ++插件系统的局限性（保持插件端和应用程序端与编译器和库版本同步）变得不切实际，并且C接口更易于维护。 如果观众规模小，同质或受您控制，这些问题就不那么重要了。
- 如果界面很丰富（在“富”的精确含义上挥手），C接口可能会变得很麻烦，并且平衡会在C ++端倾斜。
然而，第一个标准（观众）更为重要，因此只有当观众是同质的并且界面显着受益于表达性收益时，C ++界面才有意义。
我曾经用C ++制作了我开发的系统的插件接口，这是一个很大的错误。 可行，但根本不实用。 今天，我总是把界面纯粹用C语言制作，尽可能简单。 这些选择的好处非常重要。 如果您的插件编写者想要一个C ++ API，您只需编写一个调用C接口的C ++包装器。
另外一个好处是，如果您的插件编写者想要使用任何其他语言的API，那么C API将始终更容易创建绑定。
通常，将接口编写为可以依赖的某些接口标准是一个明智的想法。 这就是为什么几乎每个操作系统都提供这样的界面。 在大多数Unix上，C编译器使用与OS相同的约定，因此将它们称为C调用约定。 Windows已为此目的进行了调用。
如果你尝试使用一些编译器内部调用接口，比如C ++，那么你将成为你提到的所有问题的牺牲品。 即使编译器更新也容易让您感到困惑。
我想你在那里回答你自己的问题。 没有什么可以阻止你实现一个简单的C插件接口，并允许插件编写者用C ++实现他们的插件。 只是尝试从Netscape Plugin API的错误中学习……