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
> >>but I didn't know there was actual boost code relying on ADL with
> > 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
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))
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk