Олег Абросимов wrote:
1) This issue will continuously frustrate new users, like it was with Serialization lib.
So it will and already does. Personally, I blame Microsoft.
2) boost goal is to provide libraries that can be candidates to inclusion into the standard. I can not imagine that order of standard headers inclusion would affect my program well-formedness. It doesn't. <windows.h> is not a standard header, and currently the main issue is including <windows.h> before ASIO headers. It means that while the issue under discussion is not resolved - asio can not be targeted as a proposal for inclusion into the std. and it leads to the conclusion that it doesn't conform to boost goals. sad...
I disagree. The header order dependency is not something inherent to the ASIO library. If ASIO were to become a standard, then this platform-specific issue would be for the compiler vendor to resolve. For example, MS might have to break back compatibility by not getting the <winsock.h> stuff by default in <windows.h> unless a compiler switch is enabled.
3) I can not see why you need to include all these platform dependent definitions in each header file. I believe that applying some kind of Bridge pattern would help to localize these platform dependent definitions/declarations in .cpp files only.
ASIO is a header-only library. There are no .cpp files to hide implementation in. It's one of the downsides of header-only libraries.
4) I understand that it is not an easy task and it is up to yours to consider my opinion, but I would appreciate if you include this issue into your TODO list.
I don't see anything that can be done about it. The WinAPI headers are order-dependent. I don't see what a library can do to change that. Sebastian Redl