[ace-users] Advantages of ACE

Green, Cliff cliff.green at boeing.com
Wed Aug 1 18:08:24 CDT 2007

I've replied at least twice in the Boost mailing list about comparisons
between Boost and ACE (check the Boost list archives), and here's a few
more short summaries based on my experience.

BOOST: It is a library with lot of primitives and building blocks for
meta programming. Heavily built on C++ template functionalities.
Hence, it is highly language specific. If you are looking for a very
specific OS abstracted requirement like thread library or async IO...
BOOST has it. It intentionally lacks the interdependency between
libraries and hence mainly used as building blocks for a bigger
infrastructure library (like ACE).

I'm not sure I understand or agree completely with the above. Boost does
tend to have a large set of "building block" or core libraries, but
there's also quite a few large / high-level / "almost framework"
libraries either in the current release, or in the next major release
(e.g. check out the latest capabilities of Boost Spirit, Proto, or
Fusion - Domain Specific Embedded Language support in C++, compile time
MPL containers, full EBNF style parsing support directly in C++, etc). I
would still say that ACE has more "framework" style libraries, and maybe
a slightly higher level of abstraction in some of the services.

There's quite a bit of interdependency between libraries in Boost,
although maybe not quite as much interdependency as ACE or other
libraries, specially libraries that are highly inheritance based (e.g.
POCO - one of the disadvantages of inheritance / common base class
libraries is the coupling that results - inheritance is the highest form
of coupling between classes that you can have).

The "meta programming" libraries in Boost are only a subset of Boost.

I'm not sure what "highly language specific" is. Boost consists of C++
libraries, as does ACE and POCO (and other similar libraries). If that
means "uses most of the template facilities in C++", then definitely so.
Most C++ libraries (in my experience) are written at approximately a
late 90's typical style of C++, including ACE (if ACE was written today,
I'm sure it would be a vastly different library, taking advantage of
many more C++ features that were just starting to be used in the 90's).
POCO is a highly O-O (inheritance / interface based) library, not using
"modern / state of the art" C++ or generic design approaches. While this
is not necessarily bad, IMO libraries with that design style and
interface are better implemented in Java (or Python, or something
similar). When I write C++ libraries, I like to use the best features of
the C++ language, which for building block / "infrastructure" style
libraries typically are template based, or a mix of template and
inheritance-based designs.

Where ACE (and newer libraries such as POCO) have some advantages over
Boost is that they are more "integrated" and consistent in their
capabilities and features. Boost is a collection of libraries, with no
"overarching" / "grand" architecture or design. ACE definitely also has
wider platform support, for a number of reasons (including using a
limited set of C++ features, and many years of excellent / mature
development and support). POCO may also have a wider set of platform
support than Boost, for similar reasons of limited C++ language feature
use, and constrained class interfaces.

I use Boost and ACE as almost my full set of "portability and building
block" libraries. As more and more libraries get added to Boost, I use
less of ACE. E.g. the Asio library is now a part of Boost, which is an
excellent Proactor style library for networking (and other asynch
operations in the future, such as file I/O). Asio is the basis of a C++
language proposal, and is likely to be in the next C++ standard (which
is coming up within a few years). Many non-Boost libraries and framework
seem to ignore the models and abstractions in the C++ language (core
language and library), hence require a "learning curve" on using them,
and act as constraints on genericity and flexibility, as opposed to
libraries like Boost, which act as extensions of the C++ language /

Boost is one of the forces driving the next C++ standard - as an
example, check out some of the standards papers on C++ concepts (which
will be in the next C++ standard), and / or check out ConceptGCC, a
version of GCC which has concept support built in (experimental, of
course). Of course, a number of Boost libraries will be in the next C++
standard library. So for developers or organization thinking ahead (C++
wise), Boost is a good choice (of course for many applications /
organizations, the opposite is needed - backwards compatibility, old
compiler usage, stability, etc, and libraries such as ACE are in these
cases a better choice).


More information about the Ace-users mailing list