我一直在与Boost C++ Libraries合作很长一段时间。我绝对喜欢Boost Asio C++ library进行网络编程。但是我被介绍给另外两个库：POCO 和Adaptive Communication Environment (ACE) framework。我想知道每个人的好坏。
答案 0 :(得分：82)
正如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评论的一些答案：
我不知道多才多艺和高级。 POCO线程库提供了一些不在Boost中的功能：ActiveMethod和Activity以及ThreadPool。 IMO POCO线程也更易于使用和理解，但这是一个主观问题。
POCO网络库还支持更高级别的协议，如HTTP和SSL（也可能在boost::asio，但我不确定？）。
足够公平。
集成库的优势在于具有一致的编码，文档和一般的“外观和感觉”。
跨平台是POCO的一个重要特征，这与Boost无关。
同样，您应该只考虑POCO是否提供了您需要的功能，而不是Boost。
答案 1 :(得分：24)
我已经使用了所有这三个所以这是我的0.02美元。
我真的想投票支持Doug Schmidt并尊重他所做的所有工作，但说实话，我发现ACE有点笨拙而且难以使用。我认为图书馆需要重启。这很难说，但是我现在回避ACE，除非有令人信服的理由使用TAO，或者你需要一个代码库来在Unix变种和Windows上运行C ++。 TAO对于许多困难问题都很棒，但是学习曲线非常激烈，而且CORBA有很多批评者的理由。我想在做决定之前先做好功课。
如果您使用C ++编写代码，那么在我看来，提升是一个明智的选择。我使用了许多低级库并发现它们必不可少。我的代码的快速grep揭示了shared_ptr，program_options，regex，bind，serialization，foreach，property_tree，filesystem，tokenizer，各种迭代器扩展，alogrithm和mem_fn。这些主要是低级功能，实际上应该在编译器中。一些boost库非常通用;它可以让他们做你想做的事，但这是值得的。
Poco是一组实用程序类，它们为一些非常具体的常见任务提供功能。我发现这些库编写得很好且直观。我不必花太多时间学习文档或编写愚蠢的测试程序。我目前正在使用Logger，XML，Zip和Net / SMTP。当libxml2最后一次激怒我时，我开始使用Poco。我可以使用其他类但尚未尝试过的类，例如Data :: MySQL（我很高兴使用mysql ++）和Net :: HTTP（我对libCURL很满意）。我最终会尝试Poco的其余部分，但这不是当务之急。
答案 2 :(得分：19)
许多POCO用户报告将其与Boost一起使用，因此显然两个项目中的人都有激励措施。 Boost是一系列高质量的图书馆。但它不是一个框架。至于ACE，我过去曾经使用它，并不喜欢这个设计。此外，它对古代不合规编译器的支持已经以丑陋的方式塑造了代码库。
真正区别于POCO的是一种可扩展的设计，以及具有丰富库可用性的界面，让人想起Java或C＃带来的那些。目前，POCO中最缺乏的是异步IO。
答案 3 :(得分：10)
我最近得到了一份新工作并开始使用ACE和TAO的项目。好吧，我能说的是，ACE和TAO的工作并完全完成了他们的任务。但是图书馆的整体组织和设计是相当艰巨的......
例如，ACE的主要部分包含数百个以“ACE_”开头的类。好像他们几十年来一直忽略名称空间。
此外，许多ACE的类名也没有提供有用的信息。或者你能猜出像ACE_Dev_Poll_Reactor_Notify或ACE_Proactor_Handle_Timeout_Upcall这样的类可以用于什么？
另外，ACE的文档确实缺乏，所以除非你想要努力学习ACE（没有任何好的文档真的很难......），我不建议使用ACE，除非你真的需要{{3对于TAO，如果您不需要CORBA，请继续使用一些现代库..
答案 4 :(得分：10)
我已经将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中看不到相同的功能。我会使用其中一个或两个库。
答案 5 :(得分：7)
ACE套接字库是可靠的。如果您尝试移植套接字的标准实现，则不会出错。 ACE代码坚持严格的开发范式。较高级别的构造使用起来有点混乱。僵化的范例导致一些异常处理异常。有或者曾经是这样的情况：字符串值对被传递到异常中，其中一对为null，导致异常抛出异常将使您陷入困境。调试时，类层次的深度很繁琐。我从未尝试过其他图书馆，因此无法做出明智的评论。
答案 6 :(得分：5)
然而，POCO作为一个整体更多地以网络类型的东西为中心。我坚持Boost所以我无法帮助你，但Boost的优势在于它（相对）广泛使用。
答案 7 :(得分：4)
Boost很棒，我只听说过POCO的好东西（但从未使用过），但我不喜欢ACE，将来会避免使用它。虽然你会找到ACE的粉丝，你也会发现许多你不喜欢使用boost或poco（IME）的批评者，对我来说，它发出一个明确的信号，即ACE不是最好的工具（虽然它做的却是它说的在锡上。）
答案 8 :(得分：3)
其中我只使用过ACE。 ACE是跨平台企业网络应用程序的理想框架。它具有极强的通用性和可扩展性，并配有TAO和JAWS，可快速，强大地开发ORB和/或基于Web的应用程序。
快速掌握它可能有点令人生畏，但有很多文献和商业支持。
虽然它有点沉重，但对于规模较小的应用来说，这可能有点过分。阅读POCO的摘要听起来他们的目标是可以在嵌入式系统上运行的系统，所以我假设它可以以更轻的方式使用。我现在可以给它一个旋转：P
答案 9 :(得分：1)
我认为这是一个意见问题，几乎没有正确的答案。
根据我编写便携式Win32 / Linux服务器代码（15年以上）的经验，我个人发现boost / ACE不必要地膨胀，并且因为它们给予的小优势而引入了维护危险（也称为“dll hell”）。
ACE似乎也过时了，它是一个由“c程序员”在90年代编写的“c ++库”，它在我看来真的很明显。碰巧的是，现在我正在重新设计用Pico编写的项目，在我看来，它完全遵循ACE的想法，但在更现代的术语中，并没有那么好。
无论如何，对于高性能，高效，优雅的服务器通信，您最好不要使用其中任何一种。