Олег Абросимов 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