> I think ACE is an almost perfect model for what we want. The main
I agree there are many good things about ACE.
> things I would like to see done differently in boost are
>
> 1) Use namespaces.
> 2) Support exception handling.
> 3) Use std containers.
> 3) Use other boost libraries.
Yes and:
5) Try and keep the 'MACRO laden' implementation under control
6) Be less 'monolithic'
7) Integrate more cleanly with standard C++ I/O streams
(where possible -- extend them where needed)
The biggest issue I have with ACE is that it is just way too much
sometimes. If I want to write a simple client app to download a
web page from a URL and process it, I have to take the threading
library and everything else. Not only do I have to download it,
but I have to compile and link to it. Boost has the opportunity
to not fall into this trap from the start.
So I think we should be careful to keep it simple. I think it is
interesting that in Hugo's current implementation, no library is
required. Very nice. I won't be surprised if we need a real
library at some point, but it won't be anything like the size of
ACE.
> Section A.6.3 in C++NP describes the reasoning behind the absence of
In case anyone missed it this is C++ Network Programming by Doug
Schmidt and Steve Huston -- 2 of the prime movers in the development
of ACE.
> exceptions. But as I described in another post I think we can use a
> policy class to support a nothrow interface for people who need it.
They also discuss other issues like performance. I'm in
total agreement with you that exceptions should be the 'out-of-the-box'
policy, but if we can support BOOST_NO_EXCEPTIONS that would be nice.
As described here:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/SocketErrorConcept
Jeff
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
