ACE vs Boost vs POCO

我一直在使用Boost C ++库很长一段时间。我非常喜欢用于networking编程的Boost Asio C ++库。不过，我还介绍了另外两个库： POCO和自适应通信环境（ACE）框架。我想知道每个人的好坏。

正如rdbound所说，Boost具有“接近STL”的状态。所以，如果你不需要另一个库，坚持升压。但是，我使用POCO是因为它对我的情况有一些好处。关于POCO IMO的好事情：

更好的线程库，尤其是一个活动方法的实现。我也喜欢可以设置线程优先级的事实。
比boost::asio更全面的networking库。不过boost::asio也是一个很好的库。
包括不在Boost中的function，如XML和数据库接口等等。
它比Boost更像一个图书馆。
它有干净，现代和可以理解的C ++代码。我发现比大多数Boost库更容易理解（但我不是模板编程专家:)）。
它可以在很多平台上使用。

POCO的一些缺点是：

它有限的文件。这有些被源头容易理解的事实抵消了。
与Boost相比，它拥有更小的社区和用户群。所以，如果你在堆栈溢出的问题，例如，你得到一个答案的机会less于升压
还有待观察它将如何与新的C ++标准集成。你肯定知道这对于Boost来说不会是个问题。

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

Rahul评论的一些答案：

我不知道多function和先进。 POCO线程库提供了一些不在Boost中的function： ActiveMethod和Activity和ThreadPool 。国际海事组织POCO线程也更容易使用和理解，但这是一个主观的问题。
POCOnetworking库还提供了对HTTP和SSL等更高级协议的支持（也可能在boost::asio ，但我不确定？）。
很公平。
集成图书馆的优点是具有一致的编码，文档和一般的“外观和感觉”。
跨平台是POCO的一个重要特性，这与Boost不是一个优势。

再一次，你应该只考虑POCO，如果它提供了一些你需要的function，而不是Boost。

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

我真的想为道格·施密特（Doug Schmidt）投票，并且尊重他所做的所有工作，但说实话，我发现ACE是一个轻微的错误，很难使用。我认为这个库需要重启。这很难说，但是现在我会避开ACE，除非有令人信服的理由使用TAO，或者你需要一个单一的代码库来在Unix变种和Windows上运行C ++。 TAO对于一些难题来说是非常棒的，但是学习曲线非常激烈，而且CORBA也有许多批评者的理由。我想在做决定之前先做好你的功课。

如果你用C ++编写代码，那么在我脑海中，提升就是一件容易的事情。我使用一些低级库，并发现它们是必不可less的。快速grep我的代码揭示了shared_ptr，program_options，正则expression式，绑定，序列化，foreach，property_tree，文件系统，tokenizer，各种迭代器扩展，alogrithm和mem_fn。这些主要是编译器应该具备的低级function。一些增强库是非常通用的; 可以让他们做你想做的事情，但这是值得的。

Poco是一些实用程序类的集合，为一些非常具体的常见任务提供function。我发现这些图书馆写得很好，而且很直观。我不必花费太多时间学习文档或编写愚蠢的testing程序。我目前使用Logger，XML，Zip和Net / SMTP。当libxml2最后一次激怒我时，我开始使用Poco。还有其他的类，我可以使用，但没有尝试过，例如Data :: MySQL（我很高兴mysql ++）和Net :: HTTP（我很满意libCURL）。我最终会尝试Poco的其余部分，但这不是当务之急。

许多POCO用户报告与Boost一起使用它，所以显然在这两个项目中都有激励。 Boost是一个高质量图书馆的集合。但它不是一个框架。至于ACE，我以前用过，不喜欢这个devise。此外，它对古代不兼容的编译器的支持，以一种丑陋的方式塑造了代码库。

真正区分POCO的是一个可扩展的devise，并提供丰富的库可用性界面，让人想起那些用Java或C＃获得的界面。在这个时候，POCO最缺乏的就是asynchronousIO。

我最近find了一份新工作，并且在一个使用ACE和TAO的项目上工作。那么，我可以告诉的是，ACE和TAO的工作和完成任务。但是，图书馆的整体组织和devise是相当艰巨的。

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

另外，许多ACE的类名也不提供有用的信息。或者你可以猜测ACE_Dev_Poll_Reactor_Notify或ACE_Proactor_Handle_Timeout_Upcall可以用于哪些类？

除此之外，ACE的文档真的很缺乏，所以除非你想学习ACE，否则我不会推荐使用ACE，除非你真的需要CORBA的 TAO ，如果你不需要CORBA，继续使用一些现代化的图书馆

我已经使用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的所有书籍。无论何时我不得不扩展我们的系统的function，通常需要花费一些时间来研究要做什么，然后所需的代码量是非常小的。我发现ACE非常可靠。我也使用Boost的一些代码。我在Boost中看不到相同的function。我会使用一个或两个库。

ACE套接字库是可靠的。如果你正试图移植一个标准的socket实现，那么你不会出错。 ACE代码坚持严格的开发模式。较高层次的构造有点混乱。严格的范例导致一些exception处理exception。有或曾经有这样的情况，string值对被传递到一个exception，其中一个为空的引发exception抛出exception，将令你发愁。 debugging时，类层次的深度是繁琐的。我从来没有试过其他图书馆，所以不能做出明智的评论。

由于C ++标准委员会的人员也是Boost开发人员，Boost享有“接近STL”的地位。波科和ACE不享有这样的好处，从我的轶事经验来看，博斯特更为普遍。

但是，POCO作为一个整体更多地围绕networkingtypes的东西。我坚持Boost，所以我不能帮你，但是Boost的优点是它相对广泛的应用。

Boost非常棒，我只听说过POCO的好东西（但是从来没有用过），但是我不喜欢ACE，将来也会避免。虽然你会发现ACE的粉丝，你也会发现许多你不愿意用boost或poco（IME）获得的反对者，对我来说，发出一个明确的信号，即ACE不是最好的工具（尽pipe它是这么做的在锡上）。

在那些我只用过ACE的人中， ACE是跨平台企业networking应用程序的一个很好的框架。它具有极高的通用性和可扩展性，并且带有TAO和JAWS，可以快速，强大地开发ORB和/或基于Web的应用程序。

加快速度可能有点令人生畏，但有很多关于它的文献和商业支持。

虽然有些沉重，但是对于小规模的应用程序来说，这可能有些过火。阅读POCO的总结，听起来像是他们正在瞄准一个可以在embedded式系统上运行的系统，所以我认为它可以以更轻的方式使用。我现在可以给它一个旋转：P

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

在我编写可移植的Win32 / Linux服务器代码（15年以上）的经验中，我个人发现boost / ACE不必要的膨胀，并且引入了维护危险（也就是所谓的“dll hell”）。

ACE也似乎是可怕的过时的，它是90年代由“C程序员”编写的“C ++库”，并且在我看来确实如此。恰恰相反，现在我正在重新编写与Pico编写的项目，在我看来，它完全遵循ACE的想法，但是从更现代的angular度来看，并不是那么好。

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