C++ Python 中的 API - SWIG、重新设计或消息传递
好的，快速，希望问题很简单...
我有一个大型 C++ API，它基本上是一个具有顶级 XML 类型协议的套接字 API。这是一个公司的分布式源码包。由于某些奇怪的原因，所有源代码都被写入头文件（包括函数实现）（我猜他们认为开发人员更容易导入 H 文件，而不必担心编译多个 cpp 文件？？）。该源代码还提供 C、Java 和 .NET 版本。
我正在编写的应用程序是在 Linux 上使用 Python 编写的，需要通过 Python 使用此 API。我的三个选择似乎是要么单独运行应用程序并在它们之间传递消息协议，要么运行 SWIG（或类似的）来生成 Python 挂钩，要么将所有源代码重新实现为 Python。最终，我想让它尽可能异步（已经在应用程序的其他部分使用 Twisted）。
使用 SWIG 似乎是最快的，但是有许多自定义类型结构用于函数的传入和传出以及函数的返回，我听说这对于 SWIG 来说可能有点问题。
我宁愿不必编写消息协议，因为这会造成另一个故障点和我必须管理的两种不同语言的两个不同源代码。用 Python 重新实现 C++ 代码最终可能是一个很好的解决方案，但这需要大量的精力和时间。
我的问题是，SWIG 看起来是个好主意吗？如果是这样，我是否需要编写 C++ 文件来编译包装标头，或者我应该忘记 SWIG 并研究其他内容？
我很感激任何帮助或想法。谢谢。
编辑：原来我之前说错了...头文件中有很多源代码，但我发现了一堆 .lib 和 .a 文件也是如此。是否可以对包含的这些类型的文件使用 SWIG、Boost 或类似的方法？或者我是否需要在这些之上编写一个顶级 API 并尝试这种方式？到目前为止，我的尝试都惨遭失败。
解决方案：我最终直接从 Python 实现了自己的 API。事实证明，协议规范并没有那么复杂，C++ 库实际上让它变得比需要的更加困难。我还有一个额外的好处，那就是在异步框架内构建库，而不必使用同步调用进行线程处理。
Ok, quick, and hopefully easy question here...
I have a large C++ API that is basically a sockets API with a top level XML type protocol. This is a distributed source package from a company. All of the source code is written into header files (including function implementations) for some odd reason (I guess they figure it is easier for developers to import an H file and not have to worry about compiling multiple cpp files??). The source is also available in C, Java, and .NET.
The application that I am writing is in Python, on Linux, and needs to use this API through Python. My three options seem to be either running the applications separately with a message passing protocol between them, running SWIG (or similar) to generate a Python hook-in, or to reimplement all the source code into Python. Ultimately, I'd like to make it as asynchronous as possible (already using Twisted in other parts of the application).
Using SWIG seems to be the quickest, but there are many custom typed structures that are used in passing in and out of functions, as well as returns from functions, which I have heard can be a bit of an issue with SWIG.
I'd rather not have to write a message protocol as that creates another point of failure and two different source codes, in two different languages, that I have to manage. Reimplementing the C++ code in Python may ultimately be a good solution, but that is going to require a large amount of effort and time.
My question is, does SWIG seem like a good idea, and if so, will I need to write C++ files to compile that wrap the headers, or should I just forget SWIG and look into something else?
I appreciate any help or thoughts. Thanks.
EDIT: Turns out I misspoke earlier...there is a lot of the source code in header files, but I found a bunch of .lib and .a files as well. Is it possible to use SWIG, Boost, or similar on these types of files included? Or do I need to write a top level API over those and try that way? So far my attempts have failed miserably.
SOLUTION: I ended up just implementing my own API straight from Python. Turns out that the protocol spec was not that complex and the C++ libraries actually made it more difficult than it needed to be. I also have the added bonus of building the lib inside an asynchronous framework, instead of having to do threading with the synchronous calls.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于此类问题，SWIG 通常是我的首选解决方案。 “自定义类型”结构可以完美合理地包装。不过，您需要注意的是 SWIG 解析器的限制 如果头文件中包含所有内容。
SWIG would usually be my preferred solution for problems like this. "Custom typed" structures can be wrapped perfectly sensibly. The thing you will need to watch out for though is the limitations of the SWIG parser if you've got everything in the header files.
您应该考虑 boost_python。它为您提供了对 python/c++ 接口的大量控制，而且实际上很容易使用。有一些关于使用 boost_python 的简单教程。由于 boost_python 本身就是 C++，因此您可以避免在项目中添加第三种技术 (swig)。
You should consider boost_python. It gives you a lot of control over the python/c++ interface and it is actually easy to use. There are some simple tutorials about using boost_python. Since boost_python is c++ itself, you avoid adding a third technology (swig) into your project.