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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2004-02-25 01:20:48

> -----Original Message-----
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Eric Niebler

> David Abrahams wrote:
> > "Eric Niebler" <eric_at_[hidden]> writes:
> 
> >>Hmmm ... I was aware of the theoretical possibility of this 
> problem, 
> >>but I didn't know there was actual boost code relying on ADL with 
> >>std::min/std::max.
> > 
> > 
> > I don't see the problem.  Wasn't the intention only to replace 
> > qualified std::min and std::max with (std::min) and (std::max)?
> > 
> 
> The intention was to remove the min/max hack from win32.hpp, and then 
> fix all the places where the min/max macros would otherwise 
> wreak havoc. 
> That isn't limitted to qualified called to std::min and std::max. It 
> also includes unqualified calls to min/max, and also calls to 
> numeric_limits<foo>::max, and the declarations and invocations of all 
> min/max member functions.

Provided that usages of min/max aren't used as arguments to macros, you can
solve an evil preprocessor problem like this with an annoying but effective
preprocessor solution:

#define DO_NOT_EXPAND

std::min DO_NOT_EXPAND(a, b)
std::max DO_NOT_EXPAND(a, b)

I.e. no ADL problems and no macro expansion.

However, if this is used as a macro *argument*, secondary scannings of the token
sequence will still cause min/max to expand.

#define ID(x) x

ID(std::min DO_NOT_EXPAND(a, b)) // will (and correctly should) expand

Further, VC++ has an annoying bug that will cause it to expand anyway if it
appears in the replacement list of another macro:

#define less(a, b) ((a) < (b)) // e.g.

#define ABC less DO_NOT_EXPAND(x, y)

less DO_NOT_EXPAND(x, y) // right, expands to: less (x, y)
ABC                      // wrong, expands to: ((x) < (y))

Regards,
Paul Mensonides