From: Cliff Green (cliffg_at_[hidden])
Date: 2005-08-11 17:31:02
>>> ACE is indeed overkill for *just* networking, but it is
>>> feature-rich, fast, and *very* portable. ...
>> Yes, but I think many boost users are looking for
>>something simpler as well. ....
> Also, Boost users are looking for something that plays
>well with the C++
> Standard Library and TR1. ACE goes its own way. For
>example, ACE directory
> iterators aren't anything like STL iterators. That makes
>ACE less attractive
> to some users.
Yes, definitely! ACE is an excellent framework, but was
designed and implemented for an early 1990's average C++ /
OO programmer mentality. I'm assuming much of that was due
to when ACE was originally designed, and part of it was
due to supporting many "flavors" of C++ (and the standard
library) during the mid 90's.
I've been using ACE heavily for over a year now, and my
list of pros and cons:
o Support for a very large number of platforms
o Excellent and powerful implementation of many useful
networking related patterns
o Nicely extensible framework, for many purposes
o Covers a lot of useful, practical functionality
o Generally well tested, robust
o The C++ design and usage is not modern, which has many
far-reaching implications - no interoperability with
standard library, interface design is affected (e.g. it
was designed to not use exceptions, resulting in "two
stage object construction", in-out parameters with int
error returns, etc), use of inheritance where templates
would be more suitable (in many places).
o The documentation is either too high-level, or not
complete. The books written on ACE cover the architecture
and general usage very well, but (obviously) can't cover
every detail or use case. The Doxygen is useful in some
places, and totally useless in others (here's an example I
just looked at - "length() - get the length of the
message; "size() - get the number of bytes in the
top-level <Message_Block>", both of which are separate and
distinct, and only understandable from reading the books).
o Despite my reluctance to read code, sometimes the only
way I've been able to understand what was going on (and
what was not working right) was to read the code. Well
designed libraries should rarely (or never) require
reading the implementation code to understand semantics.
o There is not always a clear separation between what is
extensible and should be customized by the application /
user, and what is not (partly a documentation issue,
partly a design issue).
o There are too many methods that provide access to
internals - i.e. not enough logical encapsulation. There's
probably a good reason for each one, but the result is a
multitude of methods on almost all classes, many of which
have no obvious and direct use.
I'm very much looking forward to a well-designed event
multiplexor and a set of lower-level network / socket
interfaces in Boost. I've offered (and am still offering)
to assist within the constraints of my time, either on
implementation (although I can only provide limited OS
expertise), or general design (I can probably offer more
It's good to see more and more momentum and actual
offerings start to appear in this realm ...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk