[Beman]
Those are worthwhile questions.
When a new library first comes up for discussion on Boost, it is very helpful if someone says "such-and-such an existing library already does a good job with that" or maybe "such-and-such an existing library already does that, but has the follow problems...".
ACE Sockets exists but has the following problems.... er.. how long have you got? :-) (Ok, I'm exaggerating - but read on....)
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.
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. And the style is very "basic" (in order to be as portable as possible). In the end we looked around for something else and opted for a library that, although not as complete as ACE, didn't make us pay for the rest of it! I see this as a great strength of boost: 99% of the time You Only Pay For What You Use! That's why I would dearly love to see a sockets library in boost (if my current workload clears up soon I may even be able to contribute to its development). I have not been able to find a usable sockets library that fulfills the YOPFWYU mantra yet. I appreciate that there are problems with this as a comprehensive sockets library is an synergy of so many platform dependant entities. However I think if an approach similar to that use by boost.threads was taken then it is an achievable goal. As I mentioned in my previous mail, there is a higher level point where a sockets library could meet with the threads library to provide implementations of pattern level entities - in a manner similar to ACE - but without the overhead of paying for a framework (and with the benefit of more modern C++ style and techniques).
Have you used the ACE sockets and related facilities in real code? What was your experience?
Like I said, we tried! 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.
Does the ACE TCP/IP stuff mix well with other libraries?
No, no, no no! :-)
Are there a lot of dependencies between the ACE TCP/IP stuff and other ACE code?
Yes! Have I made my position clear :-) [)o IhIL..