好的，这里有一个简单的问题…
我有一个大型的c++ API，它基本上是一个带有顶级XML类型协议的套接字API。这是一个来自某公司的分布式源代码包。所有的源代码都被写入头文件(包括函数实现)，因为一些奇怪的原因(我猜他们认为导入H文件对开发人员来说更容易，而不必担心编译多个cpp文件??)。源代码也可以在C、Java和。net中获得。
我正在编写的应用程序是在Linux上的Python，并且需要通过Python使用此API。我的三个选择似乎是分别运行应用程序并在它们之间传递消息协议，运行SWIG(或类似的)以生成Python钩子，或者将所有源代码重新实现为Python。最后，我想让它尽可能地异步化(已经在应用程序的其他部分使用了Twisted)。
使用SWIG似乎是最快的，但是有许多自定义类型结构用于传入和传出函数，以及从函数返回，我听说这可能是SWIG的一个小问题。
我宁愿不必编写消息协议，因为这会创建另一个故障点和两个不同的源代码，用两种不同的语言，我必须管理。在Python中重新实现c++代码最终可能是一个很好的解决方案，但这将需要大量的精力和时间。
我的问题是，SWIG看起来像一个好主意，如果是这样，我是否需要编写c++文件来编译包装头文件，或者我应该忘记SWIG并研究其他东西?
我感谢任何帮助或想法。谢谢。EDIT:原来我之前说错了…在头文件中有很多源代码，但我发现了一堆.lib和.a文件。是否可以在这些类型的文件上使用SWIG、Boost或类似的方法?还是我需要在这些上面写一个顶层API ?到目前为止，我的尝试都失败得很惨。
解决方案:我最终只是直接从Python实现我自己的API。事实证明，协议规范并没有那么复杂，c++库实际上使它变得比需要的更加困难。我还获得了在异步框架内构建库的额外好处，而不必使用同步调用执行线程。
SWIG通常是我对此类问题的首选解决方案。"自定义类型"结构可以完全合理地包装。但是需要注意的是，如果头文件中包含所有内容，则SWIG解析器的局限性。
您应该考虑boost_python。它为您提供了对python/c++接口的大量控制，并且实际上很容易使用。有一些关于使用boost_python的简单教程。由于boost_python本身就是c++，因此您可以避免在项目中添加第三种技术(swig)。