On 12/20/06, Christopher Kohlhoff <chris@kohlhoff.com> wrote:
I'm not disagreeing. However, header-only libraries have their own advantages, such as the ability for core classes to be templates. In a separated model, given the support for external templates (effectively none), all code must be fixed and flexibility provided by runtime polymorphism. That has disadvantages.
If the raw networking code was wrapped in a very thin wrapper (that really just isolated you from the <windows.h> stuff, perhaps using untypedef'ed, but compatible types (e.g. unsigned long in place of DWORD etc) to avoid mappings, then I don't see that the wrappers need add much, if any, overhead. The real ASIO code could still be rife with templates and compile-type polymorphism. I don't see that you'd need that for the internal thin wrapper. You could even go as far as to put the wrapper implementation in a header file and have the option of using a lib that has already included it in a translation unit, or include it yourself if you don't want the lib dependancy (something I'd like to see in other boost libs, for that matter). Personally I would really like to see libraries like ASIO and Process be free of windows.h dependancies in the user headers.
Yep. Another potential disadvantage of a separated model is gratuitous copying or memory allocations resulting from mapping external to implementation types. For example, scatter-gather operations use WSABUF on windows -- if that type is to be completely hidden, then I need to copy the buffer pointers to a separate array first.
As I said above, the types need not be "completely hidden". Another possibility (not sure how viable this is here, but I have done this in other, simpler, cases) is to make the declarations you need from windows.h/ winsock2.h yourself, so you don't even need to write the #includes anywhere! Not sure if you can get around the problem of the redefinitions if winsock.h is included first that way - but just a thought. Regards, [)o IhIL..