Re: [boost] windows.h

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-04 12:54:08

Brian E. Coggins wrote:
> I just upgraded to Boost 1.35, and I now have a major problem with 
> windows.h, thanks to the Boost.Threads library now invoking Boost.DateTime 
> which on Windows #includes <windows.h>.  Besides the min and max macros, 
> there are other problems, like the fact that one of the platform headers 
> does this:
> 
> #define small char
> 
> A third party library that I am using has a class called small.  Oops. 
> There are very, very many of these things.  I'm afraid I am going to have to 
> go back to 1.34 indefinitely.

Doesn't changing include order settle the problem?

> Google pulls up a lot of messages from other users having these troubles.  I 
> don't know very much about the Boost.DateTime architecture - I have used the 
> threading library for years in its older version, but never the date/time 
> library - but to the DateTime developers I ask:  Is there any possible way 
> that this could be reworked in the future to avoid bringing windows.h into 
> the user's world?  The macros and namespace pollution are a very serious 
> problem.  Defining NOMINMAX helps a little, but on things like the "small" 
> macro I'm afraid I'm stuck.
> 
> I see from mailing list posts that DateTime is not the only Boost library to 
> do this, although certainly most of the libraries do not.  It surprises me 
> that Boost has such a nice policy on its own headers, yet allows 
> implementations to do things like this.  I know sometimes it is hard to 
> avoid, but for windows.h - which is notorious for these problems - it would 
> seem like it would be worth some contortions in the implementation to avoid 
> this.  I would be more than happy to compile and link some extra CPP files 
> to keep the HPP files clean.  To the Boost community at large I ask:  What 
> is the thinking on this?

IMO, the best solution would be to create windows.hpp that would 
redefine frequently used windows.h parts in some namespace within boost. 
Something like that is already done in Boost.Thread and interlocked.hpp, 
all this stuff just needs to be gathered somewhere to be used in 
different libraries. Header-only libraries, that is. As for compiled 
libraries, I see no problems with leaving headers of such libraries 
windows.h-free and using genuine windows.h in their cpp files.