B. Dawes wrote:
My sense with ACE is that while Boost developers know it exists, they usually aren't regular ACE users, and so have trouble judging the pros and cons.
P. Nash wrote:
We tried and tried and tried to use ACE in out project - but all we wanted from it was the sockets library. Unfortunately ACE doesn't work this way. If you start using a bit of ACE you pretty much have to use all of it. It's similar to, say, MFC. It's a framework within which you have to do things its way.
While I agree with this to some extent, I think it this is exaggerated. To maximize portability, ACE defines an OS portability layers that abstracts the higher layer functions from the OS idiosyncrasies. No question you can't use ACE without depending on this layer. Boost has similar mechanisms but not as extensive as ACE. Is your complaint with the acceptor/connector/reactor patterns used in the implementations? So mostly I see the cost of ACE as the diskspace for all the ACE features I'm not going to use on my project (eg: reliable UDP protocol implementation). Of course, since a typical project will only use some of the Boost libraries the same issue applies to Boost. P. Nash wrote:
And the style is very "basic" (in order to be as portable as possible).
Please define 'basic'? ACE actually employs a policy-based design which many wouldn't consider 'basic'. P. Nash wrote:
but without the overhead of paying for a framework (and with the benefit of more modern C++ style and techniques).
ACE has used policy-based design and patterns for years -- so I think it is not modern C++ style that is lacking. That said, one area where ACE is weaker is use and integration with the C++ standard library. Since ACE preceded the standard library it has plenty of code for collections, strings, etc that could now be just use the standard library. Another area that has been discussed on the Boost list before would be to integrate better with the C++ I/O framework. This would be a benefit because it should be easier for C++ programmers to learn and the C++ I/O framework would be forced to adapt to address reactive programming styles. B. Dawes wrote:
Have you used the ACE sockets and related facilities in real code? What was your experience?
Yes on several projects across several platforms. Positive results overall. I don't remember us ever having a critical bug related to ACE. My main complaint with ACE is that it is fairly hard to learn due to somewhat sparse user documentation and a complex implementation domain. IME, this is hardly unique to ACE. It often usually requires as much intellectual effort to learn a framework to avoid writing code as it takes to actually write code. On at least one project we had a consulting company that produced an ACE training course to help developers understand how to apply ACE. P. Nash wrote:
That said, we are using ACE elsewhere - as the foundation for the TAO implementation of CORBA. However we have fully encapsulated that and isolated it from everything else through strict compile time and run time boundaries - and we still regularly have problems with it.
Such as?
Does the ACE TCP/IP stuff mix well with other libraries?
No, no, no no! :-)
Sure, it works fine with other libraries. What other libraries were you prevented from using by using ACE?
Are there a lot of dependencies between the ACE TCP/IP stuff and other ACE code?
See above... Jeff