ACE vs Boost vs Poco vs wxWidgets

Jere.Jones picture Jere.Jones · Apr 17, 2009 · Viewed 11.6k times · Source

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

Duck picture Duck · Apr 17, 2009

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.