Win32: Overloaded std::min and std::max

Hi all, A day ago I stumbled upon a problem using std::min and std::max when having included any boost header file on Win32 machine. The following code should not compile, according to the C++ standard: float f = 47.9999f; long l = 47L; std::max(f, l); // This should fail as the arguments aren't of the same type. But using boost (and Microsoft Visual C++ .NET 2003), it magically did. I tracked down the problem and found a 'fix' in <boost_1_31_0/boost/config/platform/win32.hpp> that looks like this: -----8<----------8<----------8<----------8<----------8<----- #ifdef BOOST_MSVC #include <algorithm> // for existing std::min and std::max namespace std{ // Apparently, something in the Microsoft libraries requires the "long" // overload, because it calls the min/max functions with arguments of // slightly different type. (If this proves to be incorrect, this // whole "BOOST_MSVC" section can be removed.) inline long min(long __a, long __b) { return __b < __a ? __b : __a; } inline long max(long __a, long __b) { return __a < __b ? __b : __a; } // The "long double" overload is required, otherwise user code calling // min/max for floating-point numbers will use the "long" overload. // (SourceForge bug #495495) inline long double min(long double __a, long double __b) { return __b < __a ? __b : __a; } inline long double max(long double __a, long double __b) { return __a < __b ? __b : __a; } } using std::min; using std::max; # endif -----8<----------8<----------8<----------8<----------8<----- I think that that block of code should be removed as it is illegal to overload any function in the standard library, according to the C++ standard, and that it also makes illegal code to compile. Cheers, Dalle

A day ago I stumbled upon a problem using std::min and std::max when having included any boost header file on Win32 machine.
The following code should not compile, according to the C++ standard:
float f = 47.9999f; long l = 47L; std::max(f, l); // This should fail as the arguments aren't of the same type.
But using boost (and Microsoft Visual C++ .NET 2003), it magically did. I tracked down the problem and found a 'fix' in <boost_1_31_0/boost/config/platform/win32.hpp> that looks like this:
This workaround has been changed in Boost-1.32 and should no longer cause this problem. John.
participants (2)
-
boost@dalvander.com
-
John Maddock