这个问题与以下任何一个都不一样:
我正在运行Windows 7和Visual Studio Express 2012,但我希望不会影响这个问题的答案。
tl; dr我如何最恰当地抵消/阻止/容忍math.h中以下摘录的影响,同时仍允许使用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
背景:我正在编写一个基于文本的业余C ++项目,其总体目标远远超出了这个问题的范围。我正在使用GNU Make(熟悉和可移植性)用Cygwin g ++和cl.exe编译它,并假设一个严格符合标准的环境......到目前为止。我开始认为Windows根本不允许这样的假设。
我有一个枚举,其成员包括OVERFLOW
和UNDERFLOW
。下面描述的问题可能会迫使我改变这些名称,但我更愿意保留这些名称,因为它们最适合我的目的,尽管存在外部影响,例如Windows头文件。
GCC,Visual C ++和Mac OS X的头文件(独立于llvm-gcc)默认情况下都在math.h中定义OVERFLOW
和UNDERFLOW
以及其他非标准宏。< / p>
_POSIX_C_SOURCE
)与GCC的文档一致。 (为了补偿Apple缺乏文档,我提到这一点;我有这些标识符的历史记录。)__STDC__
宏)阻止在Visual C ++中定义a few non-standard macros。如此问题开头所示,__STDC__
宏也会阻止定义OVERFLOW
和UNDERFLOW
。一旦发现/ u开关会阻止我关注的定义,我就把它添加到我的makefile中。但后来我从crtdefs.h第44行得到了一个新错误:
error C1189: Only Win32 target supported!
这是因为不再定义_WIN32
。一些搜索表明crtdefs.h与Windows驱动程序开发工具包有关。我不是在开发一个驱动程序;我能以某种方式不使用那个标题吗?或者我只需要重命名我的枚举成员以容忍非标准的Windows行为?
答案 0 :(得分:1)
有两种可能性让人想起。
首先要确保在包含math.h
时反映特定效果,例如:
#include <math.h>
#undef OVERFLOW
#undef UNDERFLOW
现在,这可能会导致某些地方出现问题,而代码需要正确定义这些内容。但是,即使在这种情况下,您也可以修改软件,为math.h
使用不同的名称:
#include <math.h>
#undef OVERFLOW
#undef UNDERFLOW
#define MATH_H_OVERFLOW _OVERFLOW
#define MATH_H_UNDERFLOW _UNDERFLOW
您只需要确保所有源代码(已编译的代码,如库无关紧要)想要使用math.h
,使用 {{1常量而不是枚举中的常量。
第二个是要非常仔细地考虑你在这个任务中付出的努力量,与将MATH_H_*
成员简单地重命名为所做的事情所需的努力量相比较'冲突。使用enum
作为枚举(而不是Overflow
)之类的东西将是我的第一次尝试,因为两者中的信息量仍然完全相同,并且它消除了直接冲突。
是的,我知道找到一种不涉及这种方式的很好,但你应该从事软件交付的工作,而不是花费大量的时间来解决一些小问题。与您的环境: - )
答案 1 :(得分:1)
不使用具有multiple effects的/u
编译器开关,而只使用/D__STDC__=1
导致定义__STDC__
宏,而不是其他任何内容。
答案 2 :(得分:0)
在C ++ 11中,您可以使用作用域枚举:
enum class Flows { Underflow, Overflow };
现在引用Flows :: Underflow和Flows :: Overflow。
即使在C ++ 98中,最好还是使用类来模拟它:
class Flows
{
public:
enum Value { Underflow, Overflow };
};