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).
> 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
> 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
> 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
> overloads that we add in the workaround, and it's this that is the cause
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk