define WIN32_LEAN_AND_MEAN , NOMINMAX, NO ... to avoid effects of Windows.h

[Esp9527]

In the Windows.h header, if WIN32_LEAN_AND_MEAN is not defined, the preprocessor will includes other headers. So if you want to not include theses headers, you must define WIN32_LEAN_AND_MEAN before #include , else it won't have any effects

https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers

[gulrak]

Thanks for reporting this, I'm aware of this issue, but the problem is, that there are projects using this in code that includes Windows.h itself. If I decide the mode Windows.h is to be included it would collide with the way the file is included by the using module. That's why the ghc::fs code is resilient against the min/max issue by using the (std::min)(...) syntax. So I would then need to add additional options to not use WIN32_LEAN_AND_MEAN when this would lead to problems.

I will extend documentation to clarify this decision and point out that if Windows.h should be used in a special way, the proper defines have to be set by the using project, or the supported separation of declaration and implementation of ghc::filesystem should be used, to stop the pollution of the global namespace.

Sadly, the way Windows handles this offers no perfect solution.

[Esp9527]

received, that's good

[Esp9527]

maybe static library is one of the options. if use header-only, that hard to avoid effects of Windows.h.

[gulrak]

Yeah, that sure is better if Windows.h is an issue. With the helper headers fs_fwd.hpp/fs_impl.hpp or by defining GHC_FILESYSTEM_FWD everywhere else and adding a cpp with only:

#define GHC_FILESYSTEM_IMPLEMENTATION
#include <ghc/filesystem.hpp>

you get separation from Windows.h into that cpp.