ACE vs Boost vs POCO [关闭]

我使用Boost C ++库已经有一段时间了。我绝对喜欢用于网络编程的Boost Asio C ++库。但是，我被介绍给另外两个库：POCO和自适应通信环境（ACE）框架。我想知道两者的优缺点。

如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更现代，更易于使用。

对Rahul的评论的一些答案：

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

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

3. 很公平。

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

5. 跨平台是POCO的重要功能，相对于Boost而言，这并不是优势。

同样，如果POCO提供了您需要的某些功能，而BOOST中没有提供，您应该只考虑POCO。

我已经用完了这三个，所以这是我的$ 0.02。

我确实想投票支持道格·施密特（Doug Schmidt），并尊重他所做的所有工作，但是老实说，我发现ACE的漏洞百出且难以使用。我认为该库需要重新启动。很难这么说，但是除非有令人信服的理由使用TAO，否则我暂时不使用ACE，或者您需要一个代码库才能在Unix变体和Windows上运行C ++。TAO对于许多棘手的问题非常有用，但是学习曲线很激烈，这是CORBA拥有众多批评家的原因。我想只是在决定使用哪种作业之前做功课。

如果您使用C ++进行编码，那么在我看来，升压无疑是一件容易的事。我使用了许多低级库，并发现它们是必不可少的。快速浏览一下我的代码，可以发现shared_ptr，program_options，regex，bind，序列化，foreach，property_tree，文件系统，令牌化器，各种迭代器扩展，alogrithm和mem_fn。这些大多是底层功能，实际上应该在编译器中。一些Boost库非常通用。让他们做您想做的事是可行的，但这是值得的。

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

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

POCO真正与众不同的是可扩展的设计和具有丰富库可用性的接口，让人联想到Java或C＃的优点。此时，POCO最急需的是异步IO。

我已经将ACE用于具有实时限制的高性能数据采集应用程序。一个线程处理来自三十多个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中看不到相同的功能。

我最近找到了一份新工作，并从事使用ACE和TAO的项目。好吧，我能说的是，ACE和TAO可以工作并完全完成其任务。但是图书馆的整体组织和设计令人生畏。

例如，ACE的主要部分由数百个以“ ACE_”开头的类组成。好像他们已经忽略命名空间已有数十年了。

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

Additonally，ACE的文档非常缺乏，所以除非你想了解ACE硬盘的方式（这是真的很难，没有任何好的文档..），我不会推荐使用ACE，除非你真的需要TAO的CORBA，如果您不需要CORBA，请继续使用一些现代库。

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

由于C ++标准委员会中也是Boost开发人员的人数众多，因此Boost享有“接近STL”的地位。Poco和ACE并没有享受到这种好处，而从我的轶事经验来看，Boost更为广泛。

但是，POCO整体上更围绕网络类型的内容。我坚持使用Boost，所以在那里我无法为您提供帮助，但是Boost的优点是（相对）广泛使用。

Boost很棒，我只听说过关于POCO的好消息（但从未使用过），但是我不喜欢ACE，将来会避免使用它。尽管您会发现ACE的拥护者，但也会发现许多您不倾向于使用boost或poco（IME）的de贬不一的词，对我来说，这清楚地表明ACE不是最好的工具（尽管它确实做到了这一点）在锡上）。

在这些中，我只真正使用过ACE。ACE是跨平台企业网络应用程序的绝佳框架。它具有极强的通用性和可扩展性，并带有TAO和JAWS，可用于快速，强大地开发ORB和/或基于Web的应用程序。

赶上它可能会有些艰巨，但有关它的文献很多，并且有商业支持。

不过，它有些沉重，因此对于较小规模的应用程序而言，这可能有点过头了。阅读POCO的摘要，听起来好像他们的目标是可以在嵌入式系统上运行的系统，所以我假设它可以以更轻巧的方式使用。我现在可以旋转一下：P

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

以我编写可移植Win32 / Linux服务器代码的经验（超过15年），我个人发现boost / ACE不必要地膨胀，并引入了维护隐患（也称为“ dll地狱”），因为它们带来的好处很少。

ACE似乎也已经过时了，它是90年代由“ c程序员”编写的“ c ++库”，在我看来，它确实显示了出来。碰巧的是，现在我正在重新设计由Pico编写的项目，在我看来，它完全遵循了ACE的想法，但是从更现代的角度来讲，这样做并没有太大的改善。

无论如何，对于高性能，高效，优雅的服务器通信，最好不使用其中的任何一种。