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

From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2006-12-19 19:33:30

ïÌÅÇ áÂÒÏÓÉÍÏ× wrote:
> Sebastian Redl wrote:
>   
>> 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?
>   
I'm saying that any library that must include Windows headers in its own
headers for any reason is doomed to this header order dependency because
Microsoft's headers have it.
>> 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>
>
> of course it can be solved by modifying the process lib, but believe it or not - now it is header only too, like asio.
>   
It could still be solved on the side of the process library by defining
WIN32_LEAN_AND_MEAN before including windows.h. It's sort of a "only
include what you need" issue.
But I agree that the problem will occur again and again. The problem, as
I said, is that the underlying headers are, IMO, broken, and it's very
hard to work around the problem, source separation and bridge pattern aside.
> 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.
>   
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.
> 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.
>   
But it is not "such a library". It's just code that wants to use the
networking features of Windows. Every source file dealing in networking
stuff, since the creation of winsock2, has had to deal with the same
problem: define WIN32_LEAN_AND_MEAN or grab winsock2 before windows. It
has always been the rule on Windows that you have to get the networking
stuff before the other stuff. I don't see that as a valid blocking
reason. (All right, so my view may be idealistic. Still, didn't we, as
the programmers, have to deal with this long enough? Isn't it about time
MS looked forward for their headers? How much code that actually
requires Winsock1 will be compiled on VS.Net 2007 or 08 or whatever the
next version will be?)

Sebastian Redl