Python SWIG、重新设计或消息传递中的C++ API

Question

好的，很快，希望你能简单地问一个问题。。。在

我有一个大的C++ API，它基本上是一个带有顶级XML类型协议的套接字API。这是一个公司的分布式源程序包。由于一些奇怪的原因，所有的源代码都被写入头文件（包括函数实现）（我猜他们认为开发人员导入H文件更容易，而且不必担心编译多个cpp文件？？）。源代码也可以在C、Java和.NET中使用。在

我正在编写的应用程序是用Python编写的，在Linux上，需要通过Python使用这个API。我的三个选择似乎是要么使用消息传递协议分别运行应用程序，要么运行SWIG（或类似的）来生成Python钩子，要么将所有源代码重新实现到Python中。最后，我想让它尽可能的异步（已经在应用程序的其他部分使用了Twisted）。在

使用SWIG似乎是最快的，但是在传入和传出函数以及从函数返回时使用了许多自定义类型的结构，我听说SWIG可能有点问题。在

我宁愿不必编写一个消息协议，因为它会造成另一个故障点和两个不同的源代码，用两种不同的语言编写，我必须管理这些代码。在Python中重新实现C++代码可能最终是一个很好的解决方案，但这将需要大量的努力和时间。在

我的问题是，SWIG看起来是个好主意，如果是这样，我需要编写C++文件来编译包头，还是应该忘记SWIG并查看其他内容？在

我很感激你的帮助。谢谢。在

编辑：原来我之前错插了……头文件中有很多源代码，但我也发现了一堆.lib和{}文件。是否可以对这些类型的文件使用SWIG、Boost或类似的文件？或者我需要在这些基础上编写一个顶级API并尝试一下？到目前为止，我的努力失败得很惨。在

解决方案：我最终只是直接从Python实现了我自己的API。事实证明协议规范并不是那么复杂，C++库实际上使它比它更需要的更困难。我还有一个额外的好处，即在异步框架中构建lib，而不必对同步调用进行线程处理。在

Answer 1

对于此类问题，SWIG通常是我的首选解决方案。”“自定义类型”结构可以完美地包装。但是您需要注意的是limitations of the SWIG parser，如果头文件中有所有。在

Answer 2

你应该考虑boost_python。它为您提供了对python/c++接口的大量控制，而且实际上很容易使用。关于使用boost_python有一些简单的tutorials。由于boost_python本身是c++的，因此避免在项目中添加第三种技术（swig）。在