我从未使用过ACE，所以我无法对其进行评论。 据我所知，人们发现 POCO 比 ACE 更现代、更易于使用。
对 Rahul 评论的一些回答：
我不知道多功能和高级。 POCO 线程库提供了一些 Boost 中没有的功能：ActiveMethod 和 Activity 以及 ThreadPool。 IMO POCO 线程也更易于使用和理解，但这是一个主观问题。
POCO 网络库还提供对 HTTP 和 SSL 等更高级别协议的支持（可能也在 boost::asio 中，但我不确定？）。
足够公平。
集成库的优点是具有一致的编码、文档和一般“外观和感觉”。
跨平台是 POCO 的一个重要特性，这相对于 Boost 来说并不是优势。
同样，如果 POCO 提供了您需要的某些功能，而 Boost 中没有这些功能，您可能应该只考虑 POCO。
As rdbound said, Boost has a "near STL" status. So if you don't need another library, stick to Boost. However, I use POCO because it has some advantages for my situation. The good things about 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::asio is 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.
Some disadvantages of POCO are:
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.
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.
Some answers to the comments by Rahul:
I don't know about versatile and advanced. The POCO thread library provides some functionality that is not in Boost: ActiveMethod and Activity, and ThreadPool. IMO POCO threads are also easier to use and understand, but this is a subjective matter.
POCO network library also provides support for higher level protocols like HTTP and SSL (possibly also in boost::asio, but I am not sure?).
Fair enough.
Integrated library has the advantage of having consistent coding, documentation and general "look and feel".
Being cross-platform is an important feature of POCO, this is not an advantage in relation to Boost.
Again, you should probably only consider POCO if it provides some functionality you need and that is not in Boost.
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.
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.
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 用户报告将其与 Boost 一起使用，因此显然这两个项目都对人们有激励作用。 Boost 是高质量库的集合。 但它不是一个框架。 至于ACE，我过去用过它，但不喜欢它的设计。 此外，它对古老的不兼容编译器的支持以丑陋的方式塑造了代码库。
POCO 的真正区别在于可扩展的设计和具有丰富库可用性的界面，让人想起 Java 或 C# 的界面。 此时 POCO 最缺的就是异步 IO。
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.
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.
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 的文档确实很缺乏，所以除非你想以困难的方式学习 ACE（没有任何好的文档真的很难..），我不建议使用 ACE，除非你真的需要 TAO 用于 CORBA，如果您不需要 CORBA，请继续使用一些现代库。
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...
For example, the main part of ACE consists of hundreds of classes starting with "ACE_". It seems like they've ignored namespaces for decades.
Additionally, many of ACE's class names don't provide useful information either. Or can you guess what classes like ACE_Dev_Poll_Reactor_Notify or ACE_Proactor_Handle_Timeout_Upcall can be used for?
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 TAO for CORBA, If you don't need CORBA, go ahead and use some modern libraries..
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.
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.
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 是跨平台企业网络应用程序的出色框架。 它具有极其通用性和可扩展性，并配备了 TAO 和 JAWS，可以快速、强大地开发 ORB 和/或基于 Web 的应用程序。
快速掌握它可能有点令人畏惧，但有很多关于它的文献，并且可以提供商业支持。
但它有点重，所以对于规模较小的应用程序来说，它可能有点过大了。 阅读 POCO 的摘要，听起来他们的目标是一个可以在嵌入式系统上运行的系统，所以我假设它可以以更轻松的方式使用。 我现在可以尝试一下：P
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.
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
Boost 很棒，我只听说过 POCO 的优点（但从未使用过），但我不喜欢 ACE，以后会避免使用它。 虽然你会发现 ACE 的粉丝，但你也会发现许多批评者，而这些批评者是你不会用 boost 或 poco (IME) 得到的，对我来说，这发出了一个明确的信号，表明 ACE 不是最好的工具（尽管它的作用与它所说的一样）在锡上）。
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).
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.
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.
In any case for high performance, efficient, elegant server communications you might be better off not using any of them.
发布评论
评论（10）
正如rdbound所说，Boost具有“接近STL”的状态。 因此，如果您不需要另一个库，请坚持使用 Boost。 但是，我使用 POCO 因为它对我的情况有一些优势。 POCO IMO 的优点：
更好的线程库，尤其是 Active Method 实现。 我还喜欢您可以设置线程优先级。
比
boost::asio更全面的网络库。 不过boost::asio也是一个非常好的库。包括 Boost 中没有的功能，例如 XML 和数据库接口。
作为一个库，它比 Boost 更加集成。
它具有干净、现代且易于理解的 C++ 代码。 我发现它比大多数 Boost 库更容易理解（但我不是模板编程专家:)）。
它可以在很多平台上使用。
POCO 的一些缺点是：
它的文档有限。 这在一定程度上被源代码易于理解这一事实所抵消。
它的社区和用户群比 Boost 等要小得多。 因此，例如，如果您在 StackOverflow 上提出问题，获得答案的机会就会低于 Boost
它将与新的 C++ 标准集成得如何，还有待观察。 你肯定知道这对于Boost来说不会是问题。
我从未使用过ACE，所以我无法对其进行评论。 据我所知，人们发现 POCO 比 ACE 更现代、更易于使用。
对 Rahul 评论的一些回答：
我不知道多功能和高级。 POCO 线程库提供了一些 Boost 中没有的功能：
ActiveMethod和Activity以及ThreadPool。 IMO POCO 线程也更易于使用和理解，但这是一个主观问题。POCO 网络库还提供对 HTTP 和 SSL 等更高级别协议的支持（可能也在
boost::asio中，但我不确定？）。足够公平。
集成库的优点是具有一致的编码、文档和一般“外观和感觉”。
跨平台是 POCO 的一个重要特性，这相对于 Boost 来说并不是优势。
同样，如果 POCO 提供了您需要的某些功能，而 Boost 中没有这些功能，您可能应该只考虑 POCO。
As rdbound said, Boost has a "near STL" status. So if you don't need another library, stick to Boost. However, I use POCO because it has some advantages for my situation. The good things about 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. Howeverboost::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.
Some disadvantages of POCO are:
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.
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.
Some answers to the comments by Rahul:
I don't know about versatile and advanced. The POCO thread library provides some functionality that is not in Boost:
ActiveMethodandActivity, andThreadPool. IMO POCO threads are also easier to use and understand, but this is a subjective matter.POCO network library also provides support for higher level protocols like HTTP and SSL (possibly also in
boost::asio, but I am not sure?).Fair enough.
Integrated library has the advantage of having consistent coding, documentation and general "look and feel".
Being cross-platform is an important feature of POCO, this is not an advantage in relation to Boost.
Again, you should probably only consider POCO if it provides some functionality you need and that is not in Boost.
这三个我都用过，所以这是我的 0.02 美元。
我真的很想投票给 Doug Schmidt 并尊重他所做的所有工作，但说实话，我发现 ACE 有轻微的错误且难以使用。 我认为该图书馆需要重新启动。 这很难说，但我现在会回避 ACE，除非有令人信服的理由使用 TAO，或者您需要一个代码库来在 Unix 变体和 Windows 上运行 C++。 TAO 在解决许多难题上表现出色，但学习曲线很长，这也是 CORBA 受到许多批评的原因。 我想在决定使用任何一个之前先做好功课。
如果您使用 C++ 进行编码，我认为 boost 是理所当然的选择。 我使用了许多低级库并发现它们必不可少。 我的代码的快速 grep 显示了shared_ptr、program_options、regex、bind、serialization、foreach、property_tree、文件系统、tokenizer、各种迭代器扩展、alogrithm 和 mem_fn。 这些大多是真正应该包含在编译器中的低级功能。 一些 boost 库非常通用； 让他们做你想做的事可能很麻烦，但这是值得的。
Poco 是实用程序类的集合，为一些非常具体的常见任务提供功能。 我发现这些库写得很好而且直观。 我不必花太多时间研究文档或编写愚蠢的测试程序。 我目前正在使用 Logger、XML、Zip 和 Net/SMTP。 当 libxml2 最后一次激怒我时，我开始使用 Poco。 还有其他类我可以使用但还没有尝试过，例如 Data::MySQL（我对 mysql++ 很满意）和 Net::HTTP（我对 libCURL 很满意）。 我最终会尝试 Poco 的其余部分，但这不是目前的优先事项。
I've used all three so here's my $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.
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.
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 用户报告将其与 Boost 一起使用，因此显然这两个项目都对人们有激励作用。 Boost 是高质量库的集合。 但它不是一个框架。 至于ACE，我过去用过它，但不喜欢它的设计。 此外，它对古老的不兼容编译器的支持以丑陋的方式塑造了代码库。
POCO 的真正区别在于可扩展的设计和具有丰富库可用性的界面，让人想起 Java 或 C# 的界面。 此时 POCO 最缺的就是异步 IO。
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.
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.
我已将 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 中没有看到相同的功能。 我会使用其中一个或两个库。
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 和 TAO 的项目。 嗯，我可以告诉的是，ACE 和 TAO 正在工作并完全完成了他们的任务。 但是库的整体组织和设计是相当令人畏惧的......
例如，ACE的主要部分由数百个以“ACE_”开头的类组成。 看起来他们几十年来一直忽略命名空间。
此外，许多 ACE 的类名也不提供有用的信息。 或者您能猜出诸如
ACE_Dev_Poll_Reactor_Notify或ACE_Proactor_Handle_Timeout_Upcall这样的类可以用来做什么吗？另外，ACE 的文档确实很缺乏，所以除非你想以困难的方式学习 ACE（没有任何好的文档真的很难..），我不建议使用 ACE，除非你真的需要 TAO 用于 CORBA，如果您不需要 CORBA，请继续使用一些现代库。
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...
For example, the main part of ACE consists of hundreds of classes starting with "ACE_". It seems like they've ignored namespaces for decades.
Additionally, many of ACE's class names don't provide useful information either. Or can you guess what classes like
ACE_Dev_Poll_Reactor_NotifyorACE_Proactor_Handle_Timeout_Upcallcan be used for?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 TAO for CORBA, If you don't need CORBA, go ahead and use some modern libraries..
由于 C++ 标准委员会中有很多人也是 Boost 开发人员，Boost 享有“接近 STL”的地位。 Poco 和 ACE 没有享受到这种好处，从我的轶事经验来看，Boost 更广泛。
然而，POCO 整体上更以网络类型的东西为中心。 我坚持使用 Boost，所以我无法帮助你，但 Boost 的优点是它（相对）广泛的使用。
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.
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.
ACE 套接字库非常可靠。 如果您尝试移植套接字的标准实现，则不会出错。 ACE 代码坚持严格的开发范例。 更高级别的结构使用起来有点混乱。 严格的范式导致异常处理出现一些异常情况。 存在或曾经存在这样的情况：将字符串值对传递到异常中，其中一个为 null 会导致异常中抛出异常，这会让您感到困惑。 类的深度分层在调试时是繁琐的。 我从未尝试过其他库，因此无法做出明智的评论。
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 是跨平台企业网络应用程序的出色框架。 它具有极其通用性和可扩展性，并配备了 TAO 和 JAWS，可以快速、强大地开发 ORB 和/或基于 Web 的应用程序。
快速掌握它可能有点令人畏惧，但有很多关于它的文献，并且可以提供商业支持。
但它有点重，所以对于规模较小的应用程序来说，它可能有点过大了。 阅读 POCO 的摘要，听起来他们的目标是一个可以在嵌入式系统上运行的系统，所以我假设它可以以更轻松的方式使用。 我现在可以尝试一下：P
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.
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
Boost 很棒，我只听说过 POCO 的优点（但从未使用过），但我不喜欢 ACE，以后会避免使用它。 虽然你会发现 ACE 的粉丝，但你也会发现许多批评者，而这些批评者是你不会用 boost 或 poco (IME) 得到的，对我来说，这发出了一个明确的信号，表明 ACE 不是最好的工具（尽管它的作用与它所说的一样）在锡上）。
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).
我认为这确实是一个意见问题，几乎没有正确的答案。
根据我编写可移植 Win32/Linux 服务器代码的经验（15 年以上），我个人发现 boost/ACE 不必要地臃肿，并且由于它们提供的微小优势而引入了维护危险（也称为“dll 地狱”）。
ACE 似乎也过时了，它是 90 年代“c 程序员”编写的“c++ 库”，在我看来它确实如此。 恰巧，现在我正在重新设计用 Pico 编写的项目，在我看来它完全遵循了 ACE 的想法，但从更现代的角度来说，也好不到哪儿去。
无论如何，为了高性能、高效、优雅的服务器通信，您最好不要使用其中任何一个。
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.
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.
In any case for high performance, efficient, elegant server communications you might be better off not using any of them.