Poco任务管理器/ Boost线程混合和匹配

时间:2012-12-06 14:29:36

标签: c++ boost poco-libraries taskmanager

我很难决定是否应该在产品中使用Poco。 我们目前使用提升,但提升是非常低的水平。我想使用Poco中的一些功能。 目前我只需要两个,任务管理器和Timer类,但它们依赖于线程池 它使用Poco :: Thread over Boost :: Thread等。

我想删除我们当前的任务管理框架并使用Poco one,因为它更适合。 说到这一点,我担心这种情况的未来后果以及Poco对象和Boost对象的混合。

我可以看到一些其他Poco套餐的好处,也许我将来会使用它们,但是现在,我真的只需要一个好的任务经理。

这就是我看到我的选择的方式 Poco:
亲 - 我毫不费力地得到了经过良好测试的工作任务经理 Con - 我将在模块中引入另一个基础层库,混合和匹配可能是未来的问题。

升压:
亲 - 我仍然坚持,我们没有其他的依赖 Con - 编写相当于Poco任务管理器/计时器需要时间,并且不会有社区压力测试/代码检查的好处。 (我也在重新发明轮子)
Con - 我们错过了其他可能非常有用的Poco软件包,包括xml,缓存,Unicode支持等。

完全使用Poco并停止Boost
Pro - 我们可以使用Poco的所有功能,这些功能都是以更高的抽象级别编写的,我们可以快速实现功能。
Con - 如果我们将来需要Boost中的某些东西,我们将无法使用它 Con - 需要大量工作来重新使用当前使用boost的代码。

当我查看实施时,我正在走下混合它们的路线,它们看似相似,但问题已经提出,现在我不确定。
我一直在搜索关于此的文档,但我没有找到任何结论,我希望得到社群对最明智行动的回应。
我毫不怀疑更多的工程师会想要使用Poco启动,所以也许当他们搜索时他们会看到这个。

感谢您的时间。

1 个答案:

答案 0 :(得分:0)

我们在项目中使用Poco和boost混合,组合效果非常好。在我看来,boost有一套很好的低级算法,而Poco提供了一组非常有用的高级应用程序对象。两个库没有明确的界限,但这就是我们使用它们的方式。例如提升信号/插槽,foreach等,以及Poco用于线程,HTTP服务,Unicode / UTF8转换。这两个库都适用于OS X,Windows,Linux,iOS和Android的公共代码。