Template Meta-programming Based Design instead of classic Object Oriented Design ---------------------------------------------------------------------------------------------------------------- I see that almost every object there is some kind of template object.
It almost mimics the API of Boost.Asio which on its way has its limitations. I remember I needed to implement FastCGI over TCP and Unix domain sockets virtually leading to same code besides some initial bind - and it required to create the entire parser using template programming because the socket itself was template object different for UNIX and TCP.
I have strong feeling that lots of stuff can actually be done using classic OOP.
This is by far one of the most annoying things I find with the ASIO API design, and it's one of my strongest regrets that that design choice is entering the standard. I can see why it seemed like a good idea back in the day, but it's an obvious API design mistake now. Thanks to my experience with ASIO, both AFIO v1 and v2 avoid the templating of objects and APIs like the plague. It's totally unnecessary in C++ 11, and perhaps even in C++ 98. Where you need to consume or produce arbitrary scatter-gather buffers, use gsl::span<T> or equivalent. AFIO v2 has a really simple, non-template, yet just as powerful scatter-gather buffer design as ASIO yet without using a single template. It's all thanks to gsl::span<T> which takes care of the container adaptation for you. I'm very proud of that part of AFIO v2, and I'd strongly recommend all new code needing scatter-gather buffers copy that approach rather than copying ASIO, whose scatter-gather buffer support is way over wraught and over engineered for what is needed. The other reason why ASIO probably felt it needed to template everything is for arbitrary user supplied completion handlers. Yet in AFIO v2 I've reduced that to a single common shared template which (cleverly if I do say so myself) performs the sole memory allocation anywhere in AFIO v2 where we allocate the platform dependent storage for the async scatter-gather i/o alongside storage for the completion handler in a single malloc() call. This is done at the front of the async API so the rest of the API implementation then works with that type erased instance, allowing it to live in a precompiled DLL, and eliminating templates for almost all of the implementation. Now I haven't looked at BEAST yet, and BEAST is not ASIO, it's not as low level, and it may need to work with custom strings, or discontinuously stored lumps of HTTP data, so I certainly can see that char iterators are going to get used a lot, and those imply templates. That said if everything is templatised I would struggle to see the motivation. We'll see when the review begins. BTW Vinnie I assume BEAST works just fine with non-header ASIO, it might be worth doing a quick benchmark to see how much of your compile times are ASIO and how much BEAST. I would imagine it will come up. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/