Strict standards-compliance with Visual C++ - c++

Question

This question is not the same as either of these:
Setting Visual C++ Studio/Express to strict ANSI mode
Is there an equivalent to -pedantic for gcc when using Microsoft's Visual C++ compiler?
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.
GCC has a selection of documented means of cleanly preventing those definitions.
Mac OS X has a couple of undocumented means to do the same, one of which (_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.)
MSDN documents the /u command-line option as a means (via the __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?

Answer 1

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.

Answer 2

Two possibilities spring to mind.
The first is to make sure you reverse the specific effects whenever you include math.h, with something like:
#include <math.h>
#undef OVERFLOW
#undef UNDERFLOW
Now, that may also cause problems down the track somewhere with code that expects those things to be defined properly. However, even in that case, you could modify your software to use a different name for the math.h ones:
#include <math.h>
#undef OVERFLOW
#undef UNDERFLOW
#define MATH_H_OVERFLOW _OVERFLOW
#define MATH_H_UNDERFLOW _UNDERFLOW
You'd just have to ensure that all source code (already-compiled code like libraries won't matter) that wants to use the math.h ones, uses the MATH_H_* constants instead of the ones in your enumeration.
The second is to think very carefully about the amount of effort you're putting into this quest, as compared to the amount of effort it would take to simply rename your enum members to something that doesn't conflict. Something like using Overflow for your enumeration (instead of OVERFLOW) would be my first attempt since there's still exactly the same amount of information in both, and it removes the immediate conflict.
Yes, I know it would be nice to find a way that doesn't involve that, but you should be in the business of delivering software rather than spending inordinate amounts of time working around minor nitpicks with your environment :-)

Answer 3

In C++11 you can use scoped enums:
enum class Flows { Underflow, Overflow };
You now refer to Flows::Underflow and Flows::Overflow.
Even in C++98 it's good practice use simulate this with classes:
class Flows
{
public:
enum Value { Underflow, Overflow };
};