围绕共享库边界的C++接口设计

Question

假设我有两个项目.一个是应用程序,另一个是共享库,包含可以由不仅仅是这个应用程序使用的公共可重用代码.

我的应用程序使用STL,我的共享库也使用STL.这里的第一个问题是我的共享库正在使用STL.如果我在我的应用程序中构建了一个较新版本的STL,但由于没有必要重建我的共享库,那么我们将立即遇到兼容性问题.

我首先想到解决这个问题的方法是在共享库类的接口中根本不使用STL.假设我的库中有一个函数,它接受一个字符串并用它做一些事情.我会让函数原型看起来像:

void DoStuffWithStrings( char const* str );

代替:

void DoStuffWithStrings( std::string const& str );

对于字符串,这可能在不同版本的STL之间可以正常,但缺点是我们将从std::string,char*返回到std::string,这似乎会导致性能问题.

是否建议将STL对应的原始类型装箱/拆箱？当我们尝试对a执行此操作时,这会变得更糟std::list,因为我确实没有"原始类型"我们可以轻松地传递它,而无需执行某种O(n)或类似的操作.

哪种设计在这种情况下效果最好？每个的优点/缺点是什么？

Answer 1

该方法的优点之一const char*是您的库也可以从 C 调用，因此也可以从许多与 C 接口的其他语言（几乎所有的东西）调用。仅此一点就是一个非常有趣的卖点。

但是，如果您编写并维护这两个库，并且它们将仅在 C++ 中使用（比如未来 5 年），我就不会经历转换所有内容的麻烦。std::string是一回事，std::vector否则std::map不会很好地转换。除此之外，您有多少次转向另一个 STL 实现？在这些情况下，您真的会“忘记”重建您的共享库吗？此外，如果确实需要，您之后仍然可以编写/生成 C 样式包装器。

结论（偏向于我在这件事上的经验）：如果你不需要C，那就用stl。