What does define WIN32_LEAN_AND_MEAN Actually do?

Windows.h uses the macro to exclude various headers. You can see these by searching for "#ifndef WIN32_LEAN_AND_MEAN".

It's purpose is to speed up compiles. Including windows.h causes virtually every windows related header in the world to come along with it by default. Using WIN32_LEAN_AND_MEAN cuts that down.

It's probably not as relevant today as it used to be since machines are faster and more people use pre-compiled headers.

There are other reasons to still define WIN32_LEAN_AND_MEAN. For example Winsock will not be included (bad if you intend to use Winsock2) and neither will those horrible min/max macros be defined.

Quote:

Original post by BitMaster There are other reasons to still define WIN32_LEAN_AND_MEAN... and neither will those horrible min/max macros be defined.

This. The reason why every C++ application should define WIN32_LEAN_AND_MEAN - otherwise you have no std::min/std::max, which ruins portability.

There is supposed to be a separate macro, NOMINMAX, which takes care of this problem, but I haven't been able to get it to work reliably across Visual Studio versions.

Quote:

Original post by swiftcoder every C++ application should define WIN32_LEAN_AND_MEAN

I had a look back at some old C++ projects where I #include "windows.h" in more than one file and it looks like I made a header to wrap it:

// windows_lean_and_mean.h

#define WIN32_LEAN_AND_MEAN
#include "windows.h"

Is there a better way? I know there alternatives like the /D option.

Quote:

Original post by dmatter Is there a better way? I know there alternatives like the /D option.

That is the approach I take - my CMake build system is set to define several of those type of macros when it detects the compiler to be MSVC.

Quote:

Original post by BitMaster ...and neither will those horrible min/max macros be defined.

#define NOMINMAX

Note that defining NOMINMAX can break some windows headers that use it (mainly ATL).

If using gdiplus you cannot define WIN32_LEAN_AND_MEAN. Gdiplus needs some type definitions that are excluded by this macro.

I think it doesn't load alot of the MFC stuff if you use it