-----Original Message----- [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler
David Abrahams wrote:
"Eric Niebler" <eric@boost-consulting.com> 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