Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at