lug*_*e86 5 c++ user-interface ipc
我正在开发一个交互式命令行工具.该工具显示提示,用户可以输入正在处理的命令和参数.执行命令后,会出现一个新提示,用户可以继续输入命令.当在cli模式下使用时,它与gdb调试器非常相似.该工具主要使用C++编写,包含一些使用C库的包装器.
我想在我的工具上附加一个GUI(QT将是我的第一选择),但是,我不知道该怎么做.如果您在互联网上搜索,许多Unix开发人员更愿意严格分离后端和前端.所以,我正在考虑将GUI作为一个单独的可执行文件,它只使用我的命令行工具的功能.
实现这一目标的最佳方法是什么？我应该使用管道或套接字进行过程间通信吗？例如,gdb使用TCP/IP,甚至可以在与服务器不同的机器上运行GUI!(但是,此功能不是必需的).
如果使用某种IPC,通讯应该如何工作？我应该使用ASCII接口(Unix编程的艺术更喜欢这个)？这样做的好处是我的GUI只需要解析命令行工具的输出.我不必非常改变我的工具,因为如果工具写入套接字/管道或只是为了cout它没有太大的区别.如果是这样,我应该为IPC定义协议还是只解析输入/输出？
另一种方法是直接将GUI集成到我的工具中,从而只生成一个可执行文件.Insight调试器就是这样做的.Insight不只是"使用"gdb,它的程序代码中有自己的gdb.这样我就不用编写解析器,我的GUI代码只能从我的"基本代码"中调用函数.
或者我应该将命令行工具设为库,我可以将其与cli或GUI前端链接？
什么是解决我的问题的最佳方法？上述解决方案的优势/劣势是什么？你喜欢哪个？
正如您在问题中指出的，有多种方法可以构建两个软件。您想问自己三个问题：
如果一个代码段严格来说是另一层（您的情况下的 CLI 代码）之上的抽象层，则核心 CLI 功能相对成熟且稳定，而您发现 GUI 可能会经常更改，这可能建议您将 CLI 代码制作为一个库，并让 GUI 代码包含该库并“调用”CLI 代码。另一方面，如果 GUI 代码将一堆软件捆绑在一起，而 CLI 代码是一个更小、更独立的模块，并且可能会以更高的频率发生变化（想想 DVD 播放器内的 DVD），您可能会考虑使您的 GUI 成为导入不同“引擎”或 CLI 模块的框架。如果您希望两个代码段具有并排关系，例如 GUI 可能会发出 HTTP 请求来下载图像，而 CLI 代码可能会在后台执行一些 CPU 密集型数字运算，那么您可能需要探索CLI 和 GUI 都作为单独的线程运行并相互通信。[根据两个代码段的耦合程度，您可以探索单独的线程（无耦合）、偶尔的消息传递（消息队列）以使用线程和细粒度锁（非常紧密耦合）。]
将大型软件部署分解为更小的模块化单元时，单独的进程（具有在不同机器上运行的可选套接字接口）非常有用。只要您的代码仍然适合您的头脑，并且代码少于大约 10,000 行，那么增加的代码复杂性和延迟是不合理的。
从您的描述来看，CLI 代码似乎已经成熟，并且 GUI 只是一个与 CLI 交互的 shell。我还了解到您打算将代码作为可执行文件发布。因此，我认为您的用例符合将 CLI 代码制作为库，并编写与之交互的 CLI shell 和 GUI shell。