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.

Mistral

If you're having problems with ACE, contact Steve Huston at riverace.com - he's been working on ACE for a long time. When I worked with ACE at a previous company I talked to him about problems we were having and he was nice and extremely helpful. We ultimately wound up buying support from him and it was worth every penny. – Quadrat

Your title is misleading, as if you are trying to compare apples and oranges. I still cannot get why you mention wx and boost at all? – Crinkumcrankum

There is significant overlap between POCO and Boost (e.g. shared pointers, asio, program_options). Similarly, POCO and wxWidgets overlap quite a bit. – Mistral

Answer 1

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.

Stradivarius

Answer 2

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.

Stover

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 IT 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.

Estrade

wxWidgets does define it's own string and collection classes as well as a lot of cross platform utility class for file/socket etc. This is heritage from the days before C++ compilers supported the STL (or templates!) – Mide

It is a common misconception that wxWidgets is only GUI stuff, but there is lot more to it. – Mistral

@Mistral So does QT, but that does not mean that I would use it for non UI stuff :-) – Estrade

For me the problem with QT is moc... wxWidgets can do a lot without having something like moc around. Also, wxWidgets can be compiled as separate libs, so you can have only the parts you use in your application, unlike QT. (I may be wrong on this one, but I think I'm not) – Adaline