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

欺骗:

-需要配置(SWIG.i模板),有时很棘手,
-缺少对某些特殊情况的处理(请进一步参阅python属性),
-某些语言缺乏性能。

Python缺点:

1) 代码样式不一致 . C++和Python代码风格非常不同(当然是显而易见的),使目标代码更为pythOnHy的一个非常有限的可能性。例如,从getter和setter创建属性是非常重要的。看见 this q&a

2) 缺乏广泛的社区 . SWIG有一些很好的文档。但是,如果捕获到文档中没有的内容,则根本没有任何信息。没有博客也没有谷歌的帮助。因此,在这种情况下,必须大量挖掘SWIG生成的代码。。。那太可怕了,我可以说。。。

赞成的意见:

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

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

因此,我为自己总结了两个swig使用良好的案例:

2)如果需要包装C++代码 对于几种语言

1) 如果需要的话 迅速地 包 就几个

现场体验

使现代化 :

巨石

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

更新3 :
我们的图书馆使用SWIG已经三年多了。 重大变化 :python部分完全用纯python重写。原因是Python现在用于我们库的大多数应用程序。即使纯Python版本比C++包裹工作慢,用户更容易使用纯Python,而不是与本地库进行斗争。

SWIG仍然用于.NET和Java版本。

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

SWIG生成(相当丑陋)C或C++代码。对于简单的函数(可以直接翻译的东西)使用它很简单,对于更复杂的函数(例如带有输出参数的函数,需要额外的翻译步骤才能在Python中表示)使用它也相当简单。对于更强大的接口,您通常需要编写C位作为接口文件的一部分。除了简单的使用之外,您还需要了解CPython以及它如何表示对象——这并不难,但需要记住一些东西。

ctypes允许您直接访问C函数、结构和其他数据,并加载任意共享库。您不需要为此编写任何C,但需要了解C是如何工作的。你可能会说,它是SWIG的另一面:它不生成代码,也不需要在运行时使用编译器,但除了简单的使用,它确实需要你了解C数据类型、转换、内存管理和对齐等方面的工作原理。您还需要手动或自动将C结构、联合和数组转换为等效的ctypes数据结构,包括正确的内存布局。

另一方面,SWIG可用于生成多种语言的包装器(不包括需要填写的特定于语言的详细信息,如我上面提到的自定义C代码)。当包装大量SWIG可以在几乎没有帮助的情况下处理的代码时,代码生成也可以比ctypes等价物简单得多。

boost pythonIMHO它实际上比swig更容易,同时让您可以更好地控制最终的python接口。如果你使用C++,你也不需要在混合中添加任何其他语言。

根据我的经验,ctypes确实有一个很大的缺点:当出现问题时(对于任何复杂的接口来说都是如此),调试是非常困难的。

问题是,堆栈的很大一部分被ctypes/ffi magic所掩盖,并且没有简单的方法来确定您是如何到达特定点的,以及为什么参数值是这样的。。

Pyrex ,它可以充当高级Python代码和低级C代码之间的粘合剂。 lxml 例如,是用Pyrex编写的。

cType是很棒的,但是不处理C++类。我还发现ctypes比直接C绑定慢10%左右,但这在很大程度上取决于调用什么。

如果你打算使用ctypes,一定要看看Pyglet和Pyopengl项目,它们有大量的cTypebinding示例。

standard Python API . 从C和Python的角度来看,它集成得非常好。。。如果您对Perl API有任何经验,您会发现它是 非常 惊喜。

Ctypes也很好,但是正如其他人所说的,它不做C++。

你要包装的图书馆有多大?代码库的变化有多快?还有其他维护问题吗?这些都可能会影响编写Python绑定的最佳方式的选择。

我只是想补充一些我还没有提到的注意事项。

如果您想尝试使用非Cpython实现(如PyPy、IronPython或Jython),那么ctypes是唯一的选择。PyPy不允许编写C扩展,因此排除了pyrex/cython和Boost.python。出于同样的原因,ctypes是唯一适用于IronPython和jython的机制(最终,一旦它们都能正常工作)。

我发现SWIG的方法有点臃肿(一般来说,不仅仅是Python),而且如果不使用明确的思维方式编写Python代码,而不是编写干净、编写良好的Python代码,我就很难实现SWIG。将C绑定写入C++(如果使用C++),然后使用cType接口到任何C层,这是一个更直接的过程。

如果您要与之接口的库中有一个C接口作为库的一部分,那么ctypes的另一个优点是您不必编译单独的python绑定库来访问第三方库。这对于制定一个纯python解决方案,避免跨平台编译问题(针对在不同平台上提供的第三方LIB)尤其有用。必须以跨平台友好的方式将编译后的代码嵌入到您希望部署在PyPi之类的软件包中是一件痛苦的事情;关于使用SWIG或底层显式C代码的Python包,我最恼火的一点是它们在跨平台上的普遍不可用性。因此,如果你正在使用跨平台的第三方库,并在它们周围开发一个Python解决方案,那么就考虑一下这一点。

作为一个真实的例子,考虑PyGTK。这(我相信)使用SWIG生成C代码来连接GTK C调用。我在最短的时间内使用了它,但却发现设置和使用它是一件非常痛苦的事情,如果在设置时没有按照正确的顺序进行操作,通常会出现奇怪的错误。这是一次令人沮丧的经历,当我看到GTK在web上提供的interace定义时,我意识到将这些接口转换为python ctypes接口是多么简单的一个练习。一个名为PyGGI的项目诞生了,在一天之内,我能够将PyGTK重写为一个功能更强大、更有用的产品,它与GTK C面向对象接口完全匹配。而且它不需要编译C代码,因此跨平台友好。(事实上,我是在与webkitgtk进行交互之后,这并不是跨平台的)。我还可以轻松地将PyGGI部署到支持GTK的任何平台。