Re: [boost] [asio] header order dependence with <windows.h>

From: ïÌÅÇ áÂÒÏÓÉÍÏ× (olegabr_at_[hidden])
Date: 2006-12-19 12:34:14

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