Marco collision let compilation errors on Windows

[HenryAWE]

The library on Windows brings the min/max macro from some Windows SDK headers into the global namespace that will cause some library using these functions (like Boost.GIL) fail to compile.

My platform:Windows 10 64-bit Compiler: VS2017 Boost version:1.69.0

[apolukhin]

That's strange. There is a test that makes sure that windows.h does not leak into https://github.com/boostorg/stacktrace/blob/5c6740b68067cbd7070d2965bfbce32e81f680c9/test/test_impl.hpp#L15

What build flags were you using? Probably BOOST_USE_WINDOWS_H was defined?

[HenryAWE]

I checked my project settings.BOOST_USE_WINDOWS_H wasn't defined. I added a test.cpp into my project with following code #include <boost/stacktrace.hpp> #include <boost/gil.hpp> It cannot reproduce the error. But when I include the stacktrace library header before other headers in a .cpp file in my project that perviously works well,this error appeared again. It seems that some three-party libraries and Boost.Stacktrace cause this problem together. Does Boost.Stacktrace defined some macros that will affect other libraries?

Included headers of other libraries in that .cpp file

• Boost 1.69.0 (Python , GIL , ProgramOptions , Containers)
• SDL2 (I'm sure that l've not include SDL_syswm.h,which will include Windows.h)
• SDL mixer
• glew
• glm

Defined macros: ZLIB_WINAPI and marcos defined by MSVC in x64 release mode

[apolukhin]

There are two solutions to your problem:

• do not use a header only version of the Boost.Stacktrace library. Link with the WinDBG version and all your macro sufferings should be gone: https://www.boost.org/doc/libs/1_69_0/doc/html/stacktrace/configuration_and_build.html
• or define NOMINMAX for your project

Also please report the min/max issue to the GIL library. All the Boost libraries should workaround the min/max issue https://www.boost.org/development/requirements.html

I'm closing this issue, as there are workarounds and it is almost impossible to remove the windows.h inclusion from this file (PR from brave ones are welcomed!): https://github.com/boostorg/stacktrace/blob/1ad62e582aecb656faaf0c30fcf42fca4656cfbc/include/boost/stacktrace/detail/frame_msvc.ipp#L21

[mloskot]

Copied from https://github.com/boostorg/gil/issues/78#issuecomment-509376643

IMO, it is not GIL or Boost or other C++ library duty but a library's user duty to #define NOMINMAX before any Windows header, as it is suggested by LLVM/clang/libcxx infrastructure:

#ifdef min
#if !defined(_LIBCPP_DISABLE_MACRO_CONFLICT_WARNINGS)
#if defined(_LIBCPP_WARNING)
_LIBCPP_WARNING("macro min is incompatible with C++.  Try #define NOMINMAX "
                "before any Windows header. #undefing min")
#else
#warning: macro min is incompatible with C++.  #undefing min
#endif
#endif
#undef min
#endif