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

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-12-20 00:15:29

Sebastian Redl wrote:
> Oleg Abrosimov wrote:
> > 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.

Oleg, if the process lib is including windows.h then you can equally
argue that boost/process.hpp is sensitive to header ordering because
this would work:

  #include <winsock2.h>
  #include <boost/process.hpp>

and this wouldn't:

  #include <winsock2.h>
  #include <boost/process.hpp>

It should probably be modified to define WIN32_LEAN_AND_MEAN before
including before including windows.h. E.g. using the mechanism that was
described here:

http://article.gmane.org/gmane.comp.lib.boost.devel/148309

Yes, it is already on my todo list to do something about this for asio
(probably adopting the approach used by the interprocess library rather
than the bridge pattern). However there are plenty of other things that
have a higher priority, so it won't happen for quite a while.

In the meantime, it is my opinion that it is sufficient to provide the
following guarantee: if a program uses boost and std headers only, then
the headers need not be in any particular order. If a program explicitly
includes windows.h, winsock2.h or a similar header then the program has
to care about header order, because that is the nature of the Windows
SDK.

> 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.

Yep. Another potential disadvantage of a separated model is gratuitous
copying or memory allocations resulting from mapping external to
implementation types. For example, scatter-gather operations use WSABUF
on windows -- if that type is to be completely hidden, then I need to
copy the buffer pointers to a separate array first.

While I'm hopeful these problems can be solved, they are why I'm leaning
towards the approach used by interprocess as a simpler solution. That
is, to declare/define the required types and functions myself instead of
including windows header files.

> > 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.

The networking proposal doesn't say that implementations must be
header-only. An implementor can completely hide the implementation
details.

> 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?)

I'm not holding my breath ;)

Cheers,
Chris