Sebastian Redl wrote:
Олег Абросимов 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.
Sorry, what is your point here? Do you claim that boost should follow MS in this question?
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.
Actually, my code was: #include <boost/process.hpp> #include <boost/asio/deadline_timer.hpp> process - is a boost candidate library by Julio M. Merino Vidal it includes <windows.h> if this lib becomes boost lib then this header order issue will arise again and arise frequently ;-) of course it can be solved by modifying the process lib, but believe it or not - now it is header only too, like asio. and there will be other libs that deal with low-level system APIs that would suffer from the same problem again. It seams for me, that there is a need for common guideline for such a libraries in boost. The filesystem lib can be given as a starting point. It is not header only, it hides it's implementation in .cpp sources. I believe, that any lib that deals with system APIs can not be header only, it must hide it's implementation details to eliminate a chance of headers collisions and as such - should have cpp sources.
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.
Are you joking? In reality the C++ committee can be blocked by any single vendor for any reason. And there the reason is clear - backward compatibility with a huge codebase. Such a library doomed to be rejected.
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.
ok, just introduce .cpp files ;-) Best, Oleg Abrosimov