tag:blogger.com,1999:blog-8371436.post2340589982637198305..comments2023-08-11T06:11:22.868-07:00Comments on Poling Place: std::min and std::max versus Visual StudioSteve Polinghttp://www.blogger.com/profile/06095291939072131815noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8371436.post-34181767392129201672012-06-11T02:34:23.743-07:002012-06-11T02:34:23.743-07:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8371436.post-39877614333355110402008-05-29T06:38:00.000-07:002008-05-29T06:38:00.000-07:00I just had trouble using std::numeric_limits's max...I just had trouble using std::numeric_limits's max() - again - using Visual Studio 2005. Instead of just defining NOMINMAX, I investigated where windows.h actually comes from (I'm writing a service DLL that's meant to be portable). The first and most intrusive occurrence was in stdafx.h - VS.NET 2005 automatically puts it there when you create a project. They actually define WINDOWS_LEAN_AND_MEAN which is at least half correct :-)<BR/><BR/>I deleted the whole block of code and recompiled. DllMain would fail to compile, so I put #include <windows.h> there and only there. But then the linker complained about a missing definition for SomeClass::GetMessageW. The name of this method is supposed to be GetMessage. Obviously, somewhere the header containing this class is included after windows.h, which happens to #define GetMessage GetMessageW. Because windows.h used to be included everywhere throughout the project, this means that SomeClass::GetMessage was actually known to compiler and linker as GetMessageW all along! Aaargh! Good thing this problem was noticed pre-release.<BR/><BR/>Since except for the tiny main source file, there was no direct inclusion of windows.h, I used #ifdef and #error to identify the culpable third-party header - it was boost/thread/recursive_mutex.hpp - and put an #undef GetMessage after it. It's not pretty but it works for now. Sigh. Unfortunately, there is no way to be sure that this was the only name that wasn't messed up by the defines in windows.h.<BR/><BR/>Conclusion: Windows.h does not do some evil things. Windows.h IS evil.Anonymousnoreply@blogger.com