我很难决定是否应该在我们的产品中使用 Poco。 我们目前使用 boost,但 boost 的级别非常低。我想使用 Poco 中的一些功能。 目前我只需要两个,任务管理器和计时器类,但是它们依赖于线程池 它使用 Poco::Thread 而不是 Boost::Thread 等。
我想删除我们当前的任务管理框架并使用 Poco 框架,因为它更适合。 说到这里,我担心这种情况以及 Poco 对象和 Boost 对象混合的 future 后果。
我可以看到其他一些 Poco 软件包的好处,也许我将来会使用它们,但现在,我真的只需要一个好的任务管理器。
这就是我如何看待我的选择
波科:
优点 – 我毫不费力就得到了一个经过充分测试的工作任务管理器。
缺点 – 我将在模块中引入另一个基础层库,混合和
匹配可能是将来的一个问题。
boost :
专业人士 – 我仍然使用 boost,我们没有其他依赖。
缺点 – 编写相当于 Poco 任务管理器/计时器的工具需要时间,而且它不会
具有社区压力测试/代码检查的好处。 (我也在重新发明轮子)
缺点 – 我们错过了其他可能有很大帮助的 Poco 包,即 xml、缓存、Unicode 支持等。
完全使用 Poco 并停止 Boost
Pro – 我们可以使用 Poco 的所有功能,这些功能是在更高抽象级别编写的,我们可以快速实现功能。
缺点 – 如果我们将来需要 Boost 中的某些东西,我们将无法使用它。
缺点 – 重新编写当前使用 boost 的代码需要大量工作。
当我查看实现时,我正在沿着混合它们的路线,它们看起来很相似,但问题被提出了,现在我不确定。
我一直在寻找这方面的文档,但没有找到任何结论性的东西,我希望得到社区对最明智行动的回应。
我毫不怀疑更多的工程师会希望在 Poco 中使用 boot,所以也许当他们搜索时会看到这个。
感谢您的宝贵时间。
最佳答案
我们在项目中将 Poco 与 boost 混合使用,并且这种组合效果非常好。在我看来,boost 有一组很棒的低级算法,而 Poco 提供了一组非常有用的高级应用程序对象。这两个库之间没有明确的界限,但这就是我们使用它们的方式。例如boost 用于信号/槽、foreach 等,Poco 用于线程、HTTP 服务、Unicode/UTF8 转换。这两个库都适用于跨 OS X、Windows、Linux、iOS 和 Android 的通用代码。
关于c++ - Poco 任务管理器/Boost 线程混合和匹配,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13745727/