Python < C++面向对象通信

Question

<>我想在C++中编写一个守护进程，它将持有一个图形数据结构并计算一些依赖关系。我还希望有Python批处理（也有后台程序——一个基于HTML的GUI的后台），它允许用户在这些C++结构上进行交互操作。节点并读取计算结果。在

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

强制性功能是：

Python和C++应该能够以面向对象的方式操作节点，所以我希望能够编写像^ {CD1}}这样的代码
1. Python批处理不必与C++守护进程分离，它们可以有相同的生命周期（但是在C++崩溃或错误的情况下，从某种程度上可以将批处理与C++守护进程分离，这是可选的）
2. 通信应该是快速的——Python应该能够获得关于许多节点的信息，并允许最终用户尽可能顺利地工作。在

目前我在想：

1. IPC（像0MQ）具有某种数据序列化机制。在
2. 基于Protocol Buffers或{a3}的RPC。在
3. 基于Boost.Python的集成

IPC和RPC解决方案看起来不错，但是我必须编写一个大的包装器来从第1点获得功能。另一方面，我没有发现关于使用Boost.Python在C++守护进程中，我不知道它是否可能。在

Answer 1

1. 在Boost.Python可能在守护程序中使用。

2. 节约和协议缓冲区工作正常。Thrift实现了一个完整的RPC服务器，而protobuf则提供了序列化，除非去年情况有所改变。我个人更喜欢节俭。

这两种解决方案的区别在于速度(Boost.Python绝对是更快的，但是如果您指定正确的套接字选项TCP\u NODELAY等，RPC并不真正慢Boost.Python二进制文件依赖于特定版本的Python。对于Thrift，依赖性更少，尤其是当Thrift本身作为一个包安装在OS发行版中时。总之，这是一个性能和部署的问题。如果不知道通信应该有多快，以及您将在何处以及如何部署程序，就无法回答这个问题。在

UPD:你真的需要用C++编写守护进程吗？如果这是因为在图上执行的计算量很大，那么计算部分应该是C++（扩展模块）吗？扩展通常优于其他技术。在

Answer 2

我推荐西顿。它有很好的C++ integration。它给了你很大的自由，使用C++的工作非常少，也就是说几乎没有样板。C++异常成为Python异常。不过，你可以微调很多事情。你应该试试看。在