101

我使用Boost C++ 库已经有一段时间了。我非常喜欢用于网络编程的 Boost Asio C++ 库。然而，我被介绍给另外两个库：POCO和Adaptive Communication Environment (ACE) framework。我想知道每个人的好与坏。

4

10 回答 10

96

正如 rdbound 所说，Boost 具有“接近 STL”的状态。因此，如果您不需要其他库，请坚持使用 Boost。但是，我使用POCO是因为它对我的情况有一些优势。POCO IMO 的优点：

  • 更好的线程库，尤其是 Active Method 实现。我也喜欢你可以设置线程优先级的事实。

  • 比 . 更全面的网络库boost::asio。不过boost::asio也是一个很好的图书馆。

  • 包括 Boost 中没有的功能，例如 XML 和数据库接口等等。

  • 它比 Boost 更集成为一个库。

  • 它具有干净、现代且易于理解的 C++ 代码。我发现它比大多数 Boost 库更容易理解（但我不是模板编程专家 :)）。

  • 它可以在很多平台上使用。

POCO 的一些缺点是：

  • 它的文档有限。这在某种程度上被来源易于理解的事实所抵消。

  • 它的社区和用户群比 Boost 小得多。因此，例如，如果您在 Stack Overflow 上提出问题，您得到答案的机会就比 Boost 低

  • 它将如何与新的 C++ 标准集成还有待观察。你肯定知道这对 Boost 来说不是问题。

我从来没有用过ACE，所以我不能评论它。据我所知，人们发现 POCO 比 ACE 更现代、更易于使用。

对拉胡尔评论的一些回答：

  1. 我不知道多功能和高级。POCO 线程库提供了一些 Boost 中没有的功能：ActiveMethodand Activity, and ThreadPool. IMO POCO 线程也更容易使用和理解，但这是一个主观问题。

  2. POCO 网络库还提供对 HTTP 和 SSL 等更高级别协议的支持（可能也在boost::asio，但我不确定？）。

  3. 很公平。

  4. 集成库的优点是具有一致的编码、文档和一般的“外观”。

  5. 跨平台是 POCO 的一个重要特征，这与 Boost 相比并不是优势。

同样，如果 POCO 提供了您需要的一些功能并且不在 Boost 中，您可能应该只考虑 POCO。

于 2009-06-14T07:05:40.087 回答
31

我已经使用了所有三个，所以这是我的 0.02 美元。

我真的很想投票给 Doug Schmidt 并尊重他所做的所有工作，但老实说，我发现 ACE 有轻微的故障且难以使用。我认为该库需要重新启动。这很难说，但我现在会回避 ACE，除非有令人信服的理由使用 TAO，或者您需要一个代码库来在 Unix 变体和 Windows 上运行 C++。TAO 非常擅长解决许多难题，但学习曲线很紧张，CORBA 有很多批评者是有原因的。我想在决定使用任何一个之前先做好功课。

如果您使用 C++ 进行编码，那么在我看来 boost 是不费吹灰之力的。我使用了许多低级库并发现它们是必不可少的。我的代码的快速 grep 显示 shared_ptr、program_options、regex、bind、序列化、foreach、property_tree、文件系统、标记器、各种迭代器扩展、算法和 mem_fn。这些主要是真正应该在编译器中的低级功能。一些 boost 库非常通用；让他们做你想做的事可能是一项工作，但这是值得的。

Poco 是一组实用程序类，为一些非常具体的常见任务提供功能。我发现这些库写得很好而且很直观。我不必花太多时间研究文档或编写愚蠢的测试程序。我目前正在使用 Logger、XML、Zip 和 Net/SMTP。当 libxml2 最后一次激怒我时，我开始使用 Poco。还有其他类我可以使用但没有尝试过，例如 Data::MySQL（我对 mysql++ 很满意）和 Net::HTTP（我对 libCURL 很满意）。我最终会尝试 Poco 的其余部分，但这不是当前的优先事项。

于 2013-08-24T01:13:43.543 回答
22

许多 POCO 用户报告说它与 Boost 一起使用，因此很明显这两个项目中的人们都有激励措施。Boost 是高质量库的集合。但它不是一个框架。至于ACE，我以前用过，不喜欢这个设计。此外，它对古老的不兼容编译器的支持以一种丑陋的方式塑造了代码库。

POCO 真正与众不同的是一种可扩展的设计和一个具有丰富库可用性的接口，让人联想到使用 Java 或 C# 获得的那些。这时候POCO最缺的就是异步IO了。

于 2009-11-15T15:18:17.280 回答
12

我已经将 ACE 用于具有实时约束的高性能数据采集应用程序。单个线程处理来自超过 30 个 TCP/IC 套接字连接和一个串行端口的 I/O。该代码可在 32 位和 64 位 Linux 上运行。我使用的许多 ACE 类中的一些是 ACE_Reactor、ACE_Time_Value、ACE_Svc_Handler、ACE_Message_Queue、ACE_Connector。ACE 是我们项目成功的关键因素。理解如何使用 ACE 类确实需要付出很大的努力。我有所有关于 ACE 的书。每当我不得不扩展我们系统的功能时，通常需要一些时间来研究要做什么，然后所需的代码量非常少。我发现ACE非常可靠。我还使用了一些来自 Boost 的代码。我在 Boost 中看不到相同的功能。

于 2011-08-09T16:39:27.310 回答
10

我最近得到了一份新工作，并在一个使用 ACE 和 TAO 的项目上工作。好吧，我能说的是，ACE 和 TAO 工作并完全完成了他们的任务。但是图书馆的整体组织和设计相当令人生畏......

例如，ACE 的主要部分由数百个以“ACE_”开头的类组成。似乎他们几十年来一直忽略名称空间。

此外，ACE 的许多类名也不提供有用的信息。或者你能猜出什么类喜欢ACE_Dev_Poll_Reactor_Notify或ACE_Proactor_Handle_Timeout_Upcall可以用于什么？

另外，ACE 的文档真的很缺乏，所以除非你想以艰苦的方式学习 ACE（没有任何好的文档真的很难......），我不建议使用 ACE，除非你真的需要CORBA的TAO，如果你不需要 CORBA，继续使用一些现代库..

于 2010-01-18T23:20:04.117 回答
7

ACE 套接字库是可靠的。如果您尝试移植套接字的标准实现，则不会出错。ACE 代码坚持严格的开发范式。更高级别的结构使用起来有点混乱。僵化的范式会导致一些异常处理异常。在某些情况下，字符串值对被传递到异常中，其中一对为 null 会导致异常引发异常，这会让您感到困惑。类分层的深度在调试时很繁琐。我从未尝试过其他库，因此无法做出明智的评论。

于 2011-02-15T18:49:33.870 回答
6

由于 C++ 标准委员会中同时也是 Boost 开发人员的人数众多，Boost 享有“接近 STL”的地位。Poco 和 ACE 不享受这种好处，而根据我的轶事经验，Boost 更为普遍。

但是，POCO 整体上更侧重于网络类型的东西。我坚持使用 Boost，所以我无法帮助你，但 Boost 的优点是它（相对）广泛的使用。

于 2009-06-14T05:18:02.327 回答
4

Boost 很棒，我只听说过 POCO 的好消息（但从未使用过），但我不喜欢 ACE，以后会避免使用它。尽管您会发现 ACE 的粉丝，但您也会发现许多使用 boost 或 poco (IME) 时不会得到的批评者，对我来说，这向我发出了一个明确的信号，即 ACE 不是最好的工具（尽管它确实如其所说在锡上）。

于 2009-06-16T18:47:15.047 回答
3

其中我只真正使用过ACE。ACE 是一个出色的跨平台企业网络应用程序框架。它非常通用和可扩展，并带有 TAO 和 JAWS，用于快速、强大地开发 ORB 和/或基于 Web 的应用程序。

跟上它的速度可能有点令人生畏，但是有很多关于它的文献，并且可以获得商业支持。

虽然它有点重，所以对于较小规模的应用程序来说可能有点矫枉过正。阅读 POCO 的摘要，听起来他们的目标是一个可以在嵌入式系统上运行的系统，所以我假设它可以以更轻松的方式使用。我现在可以试一试：P

于 2009-06-14T04:00:11.687 回答
0

我认为这真的是一个意见问题，几乎没有正确的答案。

根据我编写可移植 Win32/Linux 服务器代码（15 年以上）的经验，我个人发现 boost/ACE 不必要地臃肿并引入了维护风险（也称为“dll 地狱”），因为它们带来的优势很小。

ACE 似乎也已经过时了，它是 90 年代“c 程序员”编写的“c++ 库”，在我看来确实如此。碰巧的是，现在我正在重新设计用 Pico 编写的项目，在我看来它完全遵循 ACE 的想法，但在更现代的术语中，并没有好多少。

在任何情况下，对于高性能、高效、优雅的服务器通信，您最好不要使用它们中的任何一个。

于 2015-06-01T16:47:28.567 回答