including windows.h causes clashing with local variable name

Question

I am including windows.h in one of my h files (in order to use CaptureStackBackTrace), in a Visual-Studio project. At first I got some compiler errors because of the use of min/max std methods and the macro with same name in windows.h, but this seems to be solved by #define NOMINMAX, as I read in other SO posts. (I say "seems" because I can't be sure till my whole project builds ok again).

The problem is that some local variable names now break the build. The line:

int grp1;

inside a class method, causes the following error:

error C2143: syntax error : missing ';' before 'constant'

while the cpp file compiles ok if I change the variable name to grp1_.

Of course I can just change the variable name, but nevertheless I've got a feeling that I am doing something wrong - am I? Or is this a known issue when including windows.h? Is there any other, more elegant solution other than changing the variable name?

Answer 1

dlg.h contains the line

#define grp1        0x0430

You could exclude it by defining WIN32_LEAN_AND_MEAN.

Answer 2

It is, to a certain degree, a problem with all library headers. C and C++ reserve names beginning with an _ for the implementation (of the standard library). Other libraries are on their own. One would hope for a namespace, or if the library must be compilable in C, some sort of naming convention, such as a prefix, but neither Windows nor Posix even do this. (In the early days, the headers for X contained a #define String, which caused no end of problems with other libraries.)

In the end, there isn't any good solution. You just have to wait until you're hit by it, and then change the name of your function. (windows.h is particularly bad, because most of the “functions” in it are in fact macros, and don't obey scope.)

Answer 3

Well, grp1 is defined as so in dlgs.h:

#define grp1        0x0430

and dlgs.h is included in windows.h, hence the clash.

You can #undef grp1 after you #include <windows.h>. Not the prettiest site, but if you include windows.h only once, you can keep those fixes at one place.