我参与了一项将一些通信、解析、数据处理功能从 Win32 移植到 Linux 的项目，并且两者都将得到支持。问题域对吞吐量和性能非常敏感。
我对 boost 和 ACE 的性能特征的经验很少。具体来说，我们想了解哪个库为线程提供了最佳性能。
任何人都可以提供一些关于两者之间相对表现的数据——记录在案的或口口相传的，或者可能是一些链接吗？
编辑
谢谢大家。确认了我们最初的想法——我们很可能会为系统级跨平台的东西选择 boost。
Tim
问问题
20684 次
11 回答
27
与使用本机操作系统线程设施相比，这两个库都不应该有任何开销。你应该看看哪个 API 更干净。在我看来，boost 线程 API 更容易使用。
ACE 更倾向于“经典的 OO”，而 boost 则倾向于借鉴 C++ 标准库的设计。例如，在 ACE 中启动一个线程需要创建一个从 ACE_Task 派生的新类，并覆盖线程运行时调用的虚拟 svc() 函数。在 boost 中，您创建一个线程并运行您想要的任何功能，这大大减少了侵入性。
于 2009-01-23T22:26:01.943 回答
19
帮自己一个忙，避开 ACE。如果你问我，这是一个不应该被编写的可怕的、可怕的图书馆。我已经工作（或者更确切地说是不得不使用它）3 年了，我告诉你它是一个设计糟糕、文档记录不充分、实现不善的垃圾，使用过时的 C++ 并建立在完全脑死亡的设计决策之上......调用 ACE “C with classes”实际上是在帮它一个忙。如果您查看它的某些构造的内部实现，您通常很难抑制您的呕吐反射。此外，我不能足够强调“糟糕的文档”方面。通常，ACE 记录函数的概念包括简单地打印函数的签名。至于它的参数的含义、它的返回值和它的一般行为，那么你 通常让你自己解决这个问题。我厌倦了不得不猜测函数可能抛出哪些异常，哪个返回值表示成功，我必须传递哪些参数才能使函数执行我需要它执行的操作，或者函数/类是否是线程安全的或不。
另一方面，Boost 使用简单，现代 C++，文档非常完善，而且它可以正常工作！Boost 是要走的路，用 ACE 打倒！
于 2009-05-08T07:42:57.337 回答
8
不要担心操作系统抽象层在线程和同步对象上的开销。线程开销实际上根本不重要（因为它只适用于线程创建，与 pimpl 化指针间接的开销相比，这已经非常慢了）。如果您发现互斥操作让您放慢了速度，那么您最好查看原子操作或重新安排您的数据访问模式以避免争用。
关于 boost 与 ACE，这是“新式”与“旧式”编程的问题。Boost 有很多仅基于标头的基于模板的恶作剧（如果您能欣赏的话，使用起来很漂亮）。另一方面，如果您习惯于 C++ 的“C with classes”风格，那么 ACE 会感觉更自然。我相信这主要是您团队的个人喜好问题。
于 2009-01-24T01:45:34.037 回答
7
我已经将 ACE 用于许多重型生产服务器。它从来没有让我失望过。它坚如磐石，现在已经工作了很多年。尝试学习了BOOST的ASIO网络框架——学不来。虽然 BOOST 是更“现代”的 C++，但它也更难用于不平凡的任务 - 如果没有“现代”C++ 经验和深厚的 STL 知识，很难正确使用
于 2009-10-16T09:34:16.707 回答
6
即使 ACE 是一种老式的 C++，它仍然有许多 boost 还没有提供的面向线程的特性。
目前我认为没有理由不使用两者（但用于不同的目的）。一旦 boost 提供了一种简单的方法来实现任务之间的消息队列，我可能会考虑放弃 ACE。
于 2009-05-08T19:36:06.223 回答
3
When it comes to ease-of-use, boost is way better than ACE. boost-asio has a more transparent API, its abstractions are simpler and can easily provide building blocks to your application. The compile-time polymorphism is judiciously used in boost to warn/prevent illegal code. ACE's uses of templates, on the other hand, is limited to generalization and is hardly ever user-centric enough to disallow illegal operations. You're more likely to discover problems at run-time with ACE.
A simple example which I can think of is ACE_Reactor - a fairly scalable and decoupled interface- but you must remember to call its "own" function if you're running its event loop in a thread different from where it was created. I spent hours to figure this out for the first time and could've easily spent days. Ironically enough its object model shows more details than it hides - good for learning but bad for abstraction.
https://groups.google.com/forum/?fromgroups=#!topic/comp.soft-sys.ace/QvXE7391XKA
于 2012-09-21T21:01:52.757 回答
2
线程实际上只是 boost 和 ACE 提供的一小部分，两者总体上并没有真正的可比性。我同意 boost 更容易使用，因为 ACE 是一个相当沉重的框架。
于 2009-01-24T01:19:15.277 回答
2
我不会将 ACE 称为“C with classes”。ACE 并不直观，但如果您花时间按预期使用该框架，您将不会后悔。
据我所知，在阅读了 Boost 的文档之后，我想使用 ACE 的框架和 Boost 的容器类。
于 2009-02-05T19:39:28.917 回答
1
使用 ACE 并协同提升。ACE 有更好的通信 API，基于 OO 设计模式，而 boost 有类似“现代 C++”的设计，并且可以很好地与容器配合使用。
于 2010-03-30T12:25:45.123 回答
1
我们开始使用 ACE，相信它会隐藏 TCP 套接字和 select 调用中 windows 和 unix 之间存在的平台差异。事实证明，事实并非如此。Ace 的选择，反应器模式，不能在 Windows 上混合套接字和标准输入，并且平台之间关于套接字可写通知的语义差异仍然存在于 ACE 级别。
当我们意识到这一点时，我们已经在使用 ACE 的线程和进程特性（后者并没有像我们希望的那样隐藏平台差异），因此我们的代码现在绑定到一个巨大的库，实际上阻止将我们的代码移植到 64 位 MinGW！
我等不及代码中最后一次使用 ACE 的那一天终于被不同的东西取代了。
于 2012-02-26T01:33:00.403 回答
0
我已经使用 ACE 很多年了 (8)，但我刚刚开始为我的下一个项目再次调查使用 boost。我正在考虑提升，因为它有一个更大的工具包（正则表达式等），并且它的一部分正在被 C++ 标准所吸收，因此长期维护应该更容易。也就是说，提升将需要一些调整。尽管 Greg 提到线程支持的侵入性较小，因为它可以运行任何（C 或静态）函数，但如果您习惯使用更类似于 ACE_Task 提供的 Java 和 C# 线程类的线程类，您有使用一点技巧来获得相同的提升。
于 2009-08-29T21:54:45.000 回答