This question is not the same as either of these:
I am running Windows 7 and Visual Studio Express 2012, but I expect neither to influence the answer to this question.
tl;dr How would I most appropriately counteract/prevent/tolerate the effects of the following excerpt from math.h, while still being allowed to compile with Visual C++?
#if !__STDC__
/* Non-ANSI names for compatibility */
#define DOMAIN _DOMAIN
#define SING _SING
#define OVERFLOW _OVERFLOW
#define UNDERFLOW _UNDERFLOW
#define TLOSS _TLOSS
#define PLOSS _PLOSS
#define matherr _matherr
Background: I'm writing a hobby text-based C++ project whose overall goals are far outside this question's scope. I'm using GNU Make (for familiarity and portability) to compile it with both Cygwin g++ and cl.exe, and assuming a strictly standards-compliant environment... so far. I'm beginning to think that Windows simply doesn't allow such an assumption.
I have an enum whose members include OVERFLOW
and UNDERFLOW
. The problem described below threatens to force me to change those names, but I would prefer to keep them because they are most appropriate for my purpose, notwithstanding outside influences such as Windows header files.
GCC, Visual C++, and Mac OS X's header files (independent of llvm-gcc) all define OVERFLOW
and UNDERFLOW
, among other non-standard macros, in math.h by default.
_POSIX_C_SOURCE
) coincides with GCC's documentation. (I mention this in the interest of compensating for Apple's lack of documentation; I have a history with these identifiers.)__STDC__
macro) of preventing the definition of a few non-standard macros in Visual C++. As shown at the beginning of this question, the __STDC__
macro also prevents definition of OVERFLOW
and UNDERFLOW
.Upon discovering that the /u switch would prevent the definitions I was concerned with, I added it to my makefile. But then I got a new error from line 44 of crtdefs.h:
error C1189: Only Win32 target supported!
This is because _WIN32
is no longer defined. A bit of searching indicated that crtdefs.h is related to the Windows Driver Development Kit. I'm not developing a driver; can I somehow not use that header? Or do I just need to rename my enum members to tolerate non-standard Windows behavior?
Instead of using the /u
compiler switch, which has multiple effects, just use /D__STDC__=1
which causes the __STDC__
macro to be defined, and nothing else.