Thread: IDE liking

Originally Posted by cpjust

Then you'd be relying on that always being in the preprocessor section of the project settings. If you lose the project settings or switch to a different compiler, you'll get the error again. If you put the #undef in the source file you won't have to worry about it happening again (and newbies reading your code long after you're gone can learn about that problem with the windows header file -- and hopefully you commented why the #undef is there).

What about conditionally defining NO_MIN_MAX before each #include of <windows.h>?

Originally Posted by laserlight

What about conditionally defining NO_MIN_MAX before each #include of <windows.h>?

I guess that would work too. I just never heard of NO_MIN_MAX until now.

i even dont know what NO_MIN_MAX is!
i gotta learn this too....

It's a define that tells the Windows headers to not define min and max.

thanks for telling me!

Are there other macros in <windows.h> that conflict with functions other than min & max? If so, are there #defines for them as well? Is there a list of all the macros you can define to undefine the bad macros?

Ugh! Too many if you are unlucky enough.

The trick is to always include windows.h last. Most headers have the needed code already to fix the conflicts. This is true of windows own headers (winsock2.h for instance which has a series of conflicts with windows.h because someone though it would be important for windows.h to include winsock.h) and third-party libraries which have more experience about it than Microsoft itself.

min-max type of conflict is one of a kind however. At least to my knowledge there's no other conflict with std:: names.