0

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

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

我可以看到其他一些 Poco 软件包的好处,也许我将来会使用它们,但现在,我真的只需要一个好的任务管理器。

这就是我如何看待我的选择
Poco :
Pro – 我毫不费力地获得了一个经过良好测试的工作任务管理器。
缺点 - 我将在模块中引入另一个基础层库,混合和
匹配可能是未来的一个问题。

Boost:
Pro – 我仍然使用 boost,我们没有其他依赖项。
缺点 - 编写 Poco 任务管理器/计时器的等效项需要时间,并且不会
获得社区压力测试/代码检查的好处。(我也在重新发明轮子)
骗局——我们错过了其他可能会很有帮助的 Poco 包,例如 xml、缓存、Unicode 支持等。

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

当我查看实现时,我正在沿着混合它们的路线前进,它们看起来很相似,但是问题已经提出,现在我不确定。
我一直在寻找这方面的文档,但没有找到任何结论,我希望得到社区对最可取的行动的回应。
我毫不怀疑更多的工程师会希望将 boot 与 Poco 一起使用,所以也许他们在搜索时会看到这一点。

谢谢你的时间。

4

1 回答 1

1

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

于 2012-12-06T15:31:32.137 回答