WIN32_LEAN_AND_MEAN vs. VC_EXTRALEAN

If I remember correctly, defining VC_EXTRALEAN does much the same as WIN32_LEAN_AND_MEAN but is used in MFC applications, since you don't explicitly include windows.h in an MFC application.

For an MFC app, use VC_EXTRALEAN, otherwise use WIN32_LEAN_AND_MEAN. Define them before including the header files.

Thank you for your answers.

Meh, screw them both. Sooner or later you end up needing something that got stripped out anyway.

Keep in mind that the macro only decreases compilation time. It doesn't make a scrap of difference for your actual program.

From MSDN:

To speed the build process, Visual C++ provides the following definitions that reduce the size of the Win32 header files by excluding some of the less common APIs:

VC_EXTRALEAN
WIN32_LEAN_AND_MEAN
VC_EXTRALEAN defines WIN32_LEAN_AND_MEAN and a number of NOservice definitions, such as NOCOMM and NOSOUND. (For a list of NOservice definitions, see the header file Windows.h and the MFC header file afxv_w32.h.)

Applications created with the Visual C++ application wizards use VC_EXTRALEAN automatically. You can manually define VC_EXTRALEAN in legacy MFC applications to speed their build process.

Non-MFC applications can define WIN32_LEAN_AND_MEAN and applicable NOservice definitions to reduce build times.

Trying to use an API excluded by these definitions causes compiler errors. If a program that defines NOCOMM or VC_EXTRALEAN tries to use PurgeComm, for example, the following errors result:

error C2065: 'PurgeComm' : undeclared identifier
error C2064: term does not evaluate to a function

Personally, I like to use VC_EXTRALEAN. I have never had any problems using that macro. Sometimes, I get into trouble when I use WIN32_LEAN_AND_MEAN and/or STRICT but usually, I get by just fine with VC_EXTRALEAN.

Like wise, if I need something I include it’s header file. Most of the things I use are already defined and/or included using the standard windows headers (or common ones I should say) (i.e. Windows.h, WindowsX.h, CommCtrl.h ComDlg.h and MMSystem.h).

I usually get by with just the first two and the last. But if I’m, working on a tool that I need I include the 3rd and 4th.

Regardless of what some of these people say, I’ve used both macros in MFC and Win32 applications. I had no problems at all. I can’t remember when I did have a problem with them either. Maybe someone could present one because the no sound or COM thing didn’t apply because… well I was including DirectX interfaces also, so they probably helped out with some of that.