[ace-users] Advantages of ACE
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
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