ACE vs Boost vs Poco vs wxWidgets

Question

I have a considerable amount of experience with ACE, Boost and wxWidgets. I have recently found the POCO libraries. Does anyone have any experience with them and how they compare to ACE, Boost and wxWidgets with regard to performance and reliability?

I am particularly interested in replacing ACE with POCO. I have been unable to get ACE to compile with VS2008 with an x64 target. I mostly use ACE_Task so I think I can replace those with Poco's threads and message queues.

Some other portions of POCO that interest me are the HTTPServer, HTTPClient, and LayeredConfiguration. Those libraries are similiar to libraries in Boost and wxWidgets but I try to limit my use of wxWidgets to GUI components and the comparable Boost libraries are... difficult.

I'm interested in any experience anyone can share about POCO, good or bad.

Answer 1

I have never used ACE, but I used Boost and Poco. I really like the coding style of Poco. The packages are consistent and the source code is easy to read. They're not template crazy like boost. In my experience I spend hours reading how to use boost - serialization package, pointer map container etc- and little time reading how to use Poco stuff. I would say they have good design and make use of templates where needed.

On the negative side they have API documentation but they don't have extensive documentation on how you would use a package. For that you usually look at example source code, or their unit tests source code.

I have the HTTPServer working on Windows/Linux without any obvious errors.

So chalk it up as 1 positive experience.

Answer 2

I have used parts of POCO now and again and found it to be a very nice lib. I largely abandoned ACE a number of years ago but POCO contains some of the same patterns - Task, Reactor, etc. I have never had any problems with it so I have to assume it is stable.

Some aspects that I like:

• it is a pretty well integrated OOP hierarchy so the components work well with each other. It has a much more cohesive feel than something like Boost which is rather piece-meal.

• the source code is available and very clear. You don't need to devote large blocks of time to understand what it is doing (ACE, at least last I looked at the source) or be a template wizard (Boost).

• Components stick close to standard C++. Exceptions are derived from std::exception; they didn't reinvent yet-another-string class, etc.

• It is surprising comprehensive. There is a lot more there than appears at first glance.

The downside:

• A matter of personal preference but the authors stick pretty much to a one class per header file model so you end up including a lot of different files.

• Limited documentation. Mostly doxygen type API pages and a couple of PDFs pointing to source examples. It's usable but considering the size of the lib it is initially difficult to figure if you are making the best use of the components.

• If there is an active community built around it, I never found it. The package is maintained by some European based company and they had a wiki but I didn't find it that active or useful.

All things considered, the downside is pretty minor. I think it is a very good library and would definitely recommend it.

Answer 3

To me it seems boost has the most traction for new C++ libraries and the fact that many of them got accepted into the upcoming C++ standard speaks for itself.

I use ACE and Boost myself and the reasons I chose them are that they are mature (especially ACE) have a large strong user community which makes sure they will be maintained and enhanced and that I can get good quality professional support. We use Remedy for our ACE/TAO support and are highly satisfied.

As ACE is a much older library than Boost and one of it's goals is to support more exotic (like embedded) platforms it does not use so much bleeding edge C++ technology as Boost. I am using a mixture of ACE and Boost and am very happy with that combination.

I don't quite know why you put wxWidgets in the match, as it is mostly a graphics UI library. But if I had to do some C++ UI projects I would go with QT, mostly because this is also a widely used library (all of the KDE desktop is built on top of QT) and therefore well maintained and I would have access to a large user base for questions and support.