[boost] windows.h

From: Brian E. Coggins (becoggins_at_[hidden])
Date: 2008-08-04 11:54:03

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.

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?

Thanks for your consideration.

Brian