Python <-> C++ 面向对象的通信答案

【问题标题】：Python <-> C++ object oriented communicationPython <-> C++ 面向对象的通信
【发布时间】：2013-05-23 05:07:26
【问题描述】：

我想用 C++ 编写一个守护进程，它将保存一个图形数据结构并计算一些依赖关系。我还想要 Python Batch（也是一个守护进程 - 基于 HTML 的 GUI 的后端），它将允许用户对这些 C++ 结构进行交互操作 - 添加/删除/连接/...节点并读取计算结果。

我很想选择最好的沟通机制。

强制功能是：

Python 和 C++ 应该能够以面向对象的方式对节点进行操作，所以我希望能够编写像 n1 = node('a'); n2 = n1.add_subnode('b'); n2.ports('test').connect(node('c')) 这样的代码
Python Batch 不必与 C++ 守护程序“分离” - 它们可以具有相同的生命周期（但最好以某种方式将批处理与 C++ 守护程序分开，以防 C++ 崩溃或出现问题 - 这种分离是可选）
通信应该很快 - Python 应该能够获取有关大量节点的信息并允许最终用户尽可能顺利地工作。

目前我在想：

具有某种数据序列化机制的 IPC（如 0MQ）。
RPC 基于Protocol Buffers 或Thrift。
基于Boost.Python的集成

IPC 和 RPC 解决方案似乎不错，但我必须编写一个大包装器才能从第 1 点获取功能。另一方面，我没有找到有关在 C++ 守护程序中使用 Boost.Python 的信息，我也不知道如果可能的话。

【问题讨论】：

标签： c++ python boost ipc rpc

【解决方案1】：

Boost.Python 可用于守护进程。
Thrift 和协议缓冲区工作正常。 Thrift 实现了一个完整的 RPC 服务器，而 protobuf，除非去年情况发生了变化，否则只提供序列化。我个人更喜欢 Thrift。

这两种解决方案之间的区别在于速度（Boost.Python 肯定更快，但如果您指定正确的套接字选项——TCP_NODELAY 等，RPC 并不是真的很慢），以及在 Boost.Python 的情况下，您的二进制文件取决于在某个版本的 Python 上。在 Thrift 的情况下，您的依赖项更少，特别是如果 Thrift 本身作为 OS 分发包安装时。无论如何，这是一个性能和部署的问题。如果不知道通信应该有多快，以及您将在何处以及如何部署程序，就无法回答。

UPD：你真的需要用 C++ 编写你的守护进程吗？如果那是因为在图上执行了大量计算，也许只有计算部分应该在 C++（扩展模块）中？扩展通常比其他技术更受欢迎。

【讨论】：

谢谢，C++ 守护进程必须用 C++ 编写，但经过一番调查，我发现了一个想法，它不一定是守护进程——它可以写成 Python 使用的一组库，使用Cython/Boost.Python。 C++ 部分是引擎盖下的编译器，它将图形编译为一些二进制机器代码。我想我找到了解决方案——让 Python 成为使用 Cython 从我的 C++ 库中调用一些函数的守护进程是非常好的解决方案。
同意。一般来说，这是最好的选择：在 Python 中实现通用控制逻辑，并将 Python 中无法完成的事情作为 C++ 实现的扩展模块提供。

【解决方案2】：

我会推荐 Cython。它有非常不错的C++ integration。它使您可以毫不费力地使用 C++，即几乎没有样板文件。 C++ 异常变成 Python 异常。不过，你可以微调很多东西。你应该试试看。

【讨论】：