【发布时间】:2014-10-30 16:47:20
【问题描述】:
我正在编写一些库,我希望它们可以在 C 和 C++ 中使用,然后用 swig 包装它们以使它们可用于 Ruby、Python、Java、Lisp,...
用 C 编写库然后用 C++ 包装库而不是用 C++ 编写然后用 C 包装有什么优点和缺点?
我能想到的唯一事情是如果库是用 C++ 编写的,那么 C 程序可能需要一个 C++ 编译器来编译,尽管我可能不正确
可能还有一些功能或东西没有包装。
我主要是在寻求经验,以了解我在做这个项目时可能会遇到什么。
【问题讨论】:
-
C++ 没有稳定的 abi,很少有语言可以链接到它,同一编译器的不同版本甚至可能无法链接。 C 有一个稳定的 abi,几乎每种语言都有一个 C ffi。
-
@sjdowling,这是一个很好的观点,但据说 swig 可以为所有语言包装 C++,尽管我不确定它是如何工作的
-
这还取决于您的图书馆的组织方式。如果它(意味着它的用户界面)严重依赖模板,您将不得不手动实例化所有模板以将它们包装起来,这对于您的应用程序可能实用,也可能不实用。除此之外,“稳定的 ABI”当然是一个论点。但是 SWIG 非常擅长包装 C++ 代码。据我了解,它创建的附加接口库(然后从 Python 等访问)导出 C ABI,因此 C++ API 的困难不会对目标语言可见。
-
我必须承认,我的经验仅限于为 Python 包装 C/C++(不适用于您提到的任何其他语言)。将自己限制为 C 肯定是一个安全的选择,但 SWIG 具有 STL 容器的所有不错的包装器,并提供了将自定义类中的运算符轻松映射到 Python 中的等效结构的方法,因此,如果面向对象是你的库的一个重要概念,首先包装 C++ 可能比将自己限制在 C 中然后在目标语言中“重建”良好的结构更容易。
-
另一个想法:既然你知道你要包装这个库,那么在编写代码时检查你是否处于 SWIG 的能力范围内应该相对容易。它可能不会施加很多限制(请参阅here),但这样可以最大限度地减少对手动解决方法的需求。当您决定包装一个经过几年开发而没有考虑到这个想法的库时,事情通常会变得更加混乱。
标签: c++ c binding shared-libraries wrapper