C++ ACE vs Boost vs POCO

ACE vs Boost vs POCO

提问by rahul

I have been working with the Boost C++ Librariesfor quite some time. I absolutely love the Boost Asio C++ libraryfor network programming. However I was introduced to two other libraries: POCO and Adaptive Communication Environment (ACE) framework. I would like to know the good and bad of each.

我使用Boost C++ 库已经有一段时间了。我非常喜欢用于网络编程的 Boost Asio C++ 库。然而，我被介绍了另外两个库：POCO和自适应通信环境 (ACE) 框架。我想知道每个人的好与坏。

采纳答案by Dani van der Meer

As rdbound said, Boost has a "near STL" status. So if you don't needanother library, stick to Boost. However, I use POCObecause it has some advantages for my situation. The good things about POCO IMO:

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

• Better thread library, especially a Active Method implementation. I also like the fact that you can set the thread priority.

• More comprehensive network library than boost::asio. However boost::asiois also a very good library.

• Includes functionality that is not in Boost, like XML and database interface to name a few.

• It is more integrated as one library than Boost.

• It has clean, modern and understandable C++ code. I find it far easier to understand than most of the Boost libraries (but I am not a template programming expert :)).

• It can be used on a lot of platforms.

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

• 比boost::asio. 不过boost::asio也是一个很好的库。

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

• 与 Boost 相比，它作为一个库的集成度更高。

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

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

Some disadvantages of POCO are:

POCO 的一些缺点是：

• It has limited documentation. This somewhat offset by the fact that the source is easy to understand.

• It has a far smaller community and user base than, say, Boost. So if you put a question on Stack Overflow for example, your chances of getting an answer are less than for Boost

• It remains to be seen how well it will be integrated with the new C++ standard. You know for sure that it will not be a problem for Boost.

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

• 它的社区和用户群比 Boost 小得多。所以如果你在 Stack Overflow 上提出一个问题，你得到答案的机会比 Boost 少

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

I never used ACE, so I can't really comment on it. From what I've heard, people find POCO more modern and easier to use than ACE.

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

Some answers to the comments by Rahul:

对 Rahul 评论的一些回答：

1. I don't know about versatile and advanced. The POCO thread library provides some functionality that is not in Boost: ActiveMethodand Activity, and ThreadPool. IMO POCO threads are also easier to use and understand, but this is a subjective matter.

2. POCO network library also provides support for higher level protocols like HTTP and SSL (possibly also in boost::asio, but I am not sure?).

3. Fair enough.

4. Integrated library has the advantage of having consistent coding, documentation and general "look and feel".

5. Being cross-platform is an important feature of POCO, this is not an advantage in relation to Boost.

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

2. POCO 网络库还提供对 HTTP 和 SSL 等更高级别协议的支持（可能也在boost::asio.

3. 很公平。

4. 集成库的优势在于具有一致的编码、文档和一般的“外观和感觉”。

5. 跨平台是 POCO 的一个重要特性，这不是 Boost 的优势。

Again, you should probably only consider POCO if it provides some functionality you need and that is not in Boost.

同样，如果 POCO 提供了一些您需要的功能，而 Boost 中没有，那么您可能应该只考虑 POCO。

回答by Dani van der Meer

I've used all three so here's my $0.02.

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

I really want to vote for Doug Schmidt and respect all the work he's done, but to be honest I find ACE mildly buggy and hard to use. I think that library needs a reboot. It's hard to say this, but I'd shy away from ACE for now unless there is a compelling reason to use TAO, or you need a single code base to run C++ on both Unix variants and Windows. TAO is fabulous for a number of difficult problems, but the learning curve is intense, and there's a reason CORBA has a number of critics. I guess just do your homework before making a decision to use either.

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

If you are coding in C++, boost is in my mind a no-brainer. I use a number of the low level libraries and find them essential. A quick grep of my code reveals shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, filesystem, tokenizer, various iterator extensions, alogrithm, and mem_fn. These are mostly low-level functionality that really ought to be in the compiler. Some boost libraries are very generic; it can be work to get them to do what you want, but it's worthwhile.

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

Poco is a collection of utility classes that provide functionality for some very concrete common tasks. I find the libraries are well-written and intuitive. I don't have to spend much time studying documentation or writing silly test programs. I'm currently using Logger, XML, Zip, and Net/SMTP. I started using Poco when libxml2 irritated me for the last time. There are other classes I could use but haven't tried, e.g. Data::MySQL (I'm happy with mysql++) and Net::HTTP (I'm happy with libCURL). I'll try out the rest of Poco eventually, but that's not a priority at this point.

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

回答by Alex

Many POCO users report using it alongside Boost, so it is obvious that there are incentives for people in both projects. Boost is a collection of high-quality libraries. But it is not a framework. As for ACE, I have used it in the past and did not like the design. Additionally, its support for ancient non-compliant compilers has shaped the code base in an ugly way.

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

What really distinguishes POCO is a design that scales and an interface with rich library availability reminiscent of those one gets with Java or C#. At this time, the most acutely lacking thing from POCO is asynchronous IO.

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

回答by Bob

I have used ACE for a very high performance data acquisition application with real time constraints. A single thread handles I/O from over thirty TCP/IC socket connections and a serial port. The code runs on both 32 and 64 bit Linux. A few of the many ACE classes I have used are the ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue, ACE_Connector. ACE was a key factor to the success of our project. It does take a significant effort to understand how to use the ACE classes. I have all the books written about ACE. Whenever I have had to extend the functionality our system it typically takes some time to study what to do and then the amount of code required is very small. I have found ACE to very reliable. I also use a little bit of code from Boost. I do not see the same functionality in Boost. I would use either or both libraries.

我已经将 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 中没有看到相同的功能。

回答by smerlin

I recently got a new job and work on a project that uses ACE and TAO. Well, what I can tell is, that ACE and TAO work and fully accomplish their tasks. But the overall organisation and design of the libraries are quite daunting...

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

For example, the main part of ACE consists of hundreds of classes starting with "ACE_". It seems like they've ignored namespaces for decades.

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

Additionally, many of ACE's class names don't provide useful information either. Or can you guess what classes like ACE_Dev_Poll_Reactor_Notifyor ACE_Proactor_Handle_Timeout_Upcallcan be used for?

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

Additonally, the documentation of ACE is really lacking, so unless you want to learn ACE the hard way (it is really hard without any good documentation..), I would NOT recommend using ACE, unless you really need TAOfor CORBA, If you don't need CORBA, go ahead and use some modern libraries..

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

回答by Dan

The ACE socket libraries are solid. If you are trying to port a standard implementation of sockets you can't go wrong. The ACE code sticks to a rigid development paradigm. The higher level contructs are a little confusing to use. The rigid paradigm causes some anomolies with exception handling. There are or used to be situations where string value pairs being passed into an exception with one of the pair being null causes an exception throw in the exception that will boggle you. The depth of the class layering is tedious when debugging. I have never tried the other libraries so can't make an intelligent comment.

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

回答by rlbond

Boost enjoys a "near STL" status due to the number of people on the C++ standards committee who are also Boost developers. Poco and ACE do not enjoy that benefit, and from my anecdotal experience Boost is more widespread.

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

However, POCO as a whole is more centered around network-type stuff. I stick to Boost so I can't help you there, but the plus for Boost is its (relatively) widespread use.

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

回答by Patrick

Boost is great, I've only heard good things about POCO (but never used) but I don't like ACE and would avoid it in future. Although you will find fans of ACE you will also find many detractors which you don't tend to get with boost or poco (IME), to me that sends a clear signal that ACE is not the best tool (although it does what it says on the tin).

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

回答by Gerald

Out of those I've only ever really used ACE. ACE is a great framework for cross-platform enterprise networking applications. It's extremely versatile and scalable and comes with TAO and JAWS for quick, powerful development of ORB and/or Web based applications.

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

Getting up to speed with it can be somewhat daunting, but there is a lot of literature on it, and commercial support available.

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

It's somewhat heavy though, so for smaller-scale apps it may be a bit of an overkill. Reading the summary for POCO it sounds like they're aiming for a system that can be run on embedded systems so I'm assuming it can be used in a much lighter way. I may now give it a whirl :P

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

回答by a o

I think it is really matter of an opinion, there is hardly a right answer.

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

In my experience with writing portable Win32/Linux server code (15+ years), I personally find boost/ACE unnecessarily bloated and introduces maintenance hazards (otherwise known as "dll hell") for the little advantage they give.

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

ACE also seems to be horribly outdated, it is a "c++ library" written by "c programmers" in the 90-s and it really shows in my opinion. It so happens, right now I am re-engineering the project written with Pico, it seems to me it completely follows the ACE idea, but in more contemporary terms, not much better at that.

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

In any case for high performance, efficient, elegant server communications you might be better off not using any of them.

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