[boost] Re: win32.hpp and min/max macros

From: Sam Saariste (ss_march2001_at_[hidden])
Date: 2003-12-30 11:20:00

> > It seems extremely unwise to be undef'ing min and max.  Evil though they
> > are, many Win32 platform headers (and users' headers!) depend on them,
> > and there is simply no way to write a template or set of overloads that
> > behave exactly as the macros do.
>
Andrei Alexandrescu's template implementation seems to do an excellent job
(at least on a compliant compiler).
http://www.cuj.com/documents/s=7996/cujcexp1904alexandr/alexandr.htm

> I agree - but there is plenty of boost code that relies on std::min and
> std::max *not* being macros - were we not to do this then a fair portion
of
> Boost would just stop working :-(
>
> There is BTW a trivial fix for your problem: include the windows headers
> *before* any Boost ones.
>
Windows headers introduce a lot of macros and other polution into the global
namespace. For this reason, it's often undesirable to include those headers
first.

> However, there is also a bug in our workaround - we haven't include
> <algorithm> to get the template min/max functions as well as the
additional
> overloads that we add in the workaround, and it's this that is the cause
of
> the error in this case, I'm committing a revised win32.hpp which will now
> compile the sample you posted (or will be as soon as the config regression
> tests complete).
>
In the past I ran into another issue with the boost min/max workaround: some
other third party libraries define min/max macros if they haven't already
been defined. If the boost workaround where to use
#define min min
#define max max
instead of undef'ing them, this problem would be avoided. Any reason why
this would not be a good idea for win32.hpp?

Regards,
Sam