Python:SWIG 与 ctypes

Question

在 python 中，在什么情况下 SWIG 比 ctypes 更适合调用共享库中的入口点？假设您还没有 SWIG 接口(interface)文件。

两者的性能指标是什么？

Answer 1

我有丰富的 swig 使用经验。 SWIG 声称它是包装元素的快速解决方案。但在现实生活中……

---

缺点:

SWIG 被开发为通用的，适用于所有人和 20 多种语言。一般会导致弊端:
- 需要配置(SWIG .i 模板)，有时很棘手，
- 对某些特殊情况缺乏处理(进一步参见python属性)，
- 某些语言缺乏性能。

Python 的缺点:

1) 代码风格不一致。 C++ 和 python 有非常不同的代码风格(这是显而易见的，当然)，让目标代码更 Pythonish 的可能性非常有限。例如，从 getter 和 setter 创建属性是很重要的。见 this q&a

2) 缺乏广泛的社区。 SWIG 有一些很好的文档。但是，如果有人发现文档中没有的内容，则根本没有任何信息。没有博客和谷歌搜索有帮助。所以在这种情况下必须大量挖掘 SWIG 生成的代码......这太糟糕了，我可以说......

优点:

• 在简单的情况下，它确实快速、简单、直接

• 如果你曾经生成过 swig 接口(interface)文件，你可以将这个 C++ 代码包装到其他 20 多种语言中的任何一种(!!!)。

• 对 SWIG 的一大担忧是性能。由于 2.04 版 SWIG 包含“-builtin”标志，这使得 SWIG 比其他自动包装方式更快。至少 some benchmarks 显示了这一点。

---

什么时候使用 SWIG？

所以我给自己总结了两个swig好用的案例:

2) 如果需要为多种语言包装 C++ 代码。或者，如果可能有一段时间需要为多种语言分发代码。在这种情况下，使用 SWIG 是可靠的。

1) 如果需要快速从某个 C++ 库中包装几个函数以供最终使用。

---

现场体验

更新:
一年半过去了，我们使用 SWIG 对我们的库进行了转换。

首先，我们制作了一个 python 版本。有好几次我们在使用 SWIG 时遇到了麻烦——这是真的。但现在我们将库扩展到 Java 和 .NET。所以我们有 3 种语言和 1 个 SWIG。我可以说 SWIG 摇滚 在节省大量时间方面。

更新 2:
我们为这个库使用 SWIG 已经两年了。 SWIG 已集成到我们的构建系统中。最近我们对 C++ 库的 API 进行了重大更改。 SWIG 工作得很好。我们唯一需要做的就是在 .i 文件中添加几个 %rename，以便我们的 CppCamelStyleFunctions() 现在在 python 中 looks_more_pythonish。首先，我担心可能出现的一些问题，但没有出现任何问题。这是惊人的。只需进行几次编辑，所有内容都以 3 种语言分发。现在我相信在我们的案例中使用 SWIG 是一个很好的解决方案。

更新 3:
我们为我们的图书馆使用 SWIG 已经 3 年多了。 重大变化:python 部分完全用纯 python 重写。原因是 Python 现在用于我们库的大多数应用程序。即使纯 python 版本的工作速度比 C++ 包装慢，用户使用纯 python 更方便，而不是为原生库而苦恼。

SWIG 仍用于 .NET 和 Java 版本。

这里的主要问题“如果我们从头开始项目，我们会为 python 使用 SWIG 吗？”。我们会! SWIG 使我们能够将我们的产品快速分发为多种语言。它工作了一段时间，让我们有机会更好地了解我们的用户需求。