对于额外的积分,我也很好奇这个简单标量初始化错误背后的基本原理-我可以看到为什么跳过构造函数可能会有问题,但是在上面的例子中初始化
下面的c++示例使用gcc或clang编译失败,但是使用ICC只生成一个警告,而使用MSVC则什么都没有:
int main(int argc, char *argv[])
{
if (argc < 2)
goto clean_up;
#if 1 // FAIL
int i = 0;
#elif 0 // workaround - OK
{
int i = 0;
}
#else // workaround - OK
int i;
i = 0;
#endif
clean_up:
return 0;
}
g++:
init.cpp:13: error: jump to label ‘clean_up’
init.cpp:4: error: from here
init.cpp:7: error: crosses initialization of ‘int i’
叮当声+ +:
init.cpp:4:9: error: cannot jump from this goto statement to its label
goto clean_up;
^
init.cpp:7:9: note: jump bypasses variable initialization
int i = 0;
^
ICC:
init.cpp(4): warning #589: transfer of control bypasses initialization of:
variable "i" (declared at line 7)
goto clean_up;
^
我理解错误的原因,对于这样一个简单的例子,它是相当容易解决的(我在上面的例子中包含了几个可能的解决方案),但我正在处理一个大型的跨平台遗留代码库,其中充斥着使用类似goto
结构的错误处理宏。其他使用MSVC或ICC的开发人员不断引入内联初始化,这些初始化随后导致gcc或clang构建错误(当然,他们只是忽略了MSVC/ICC的警告)。
所以我需要找到一种方法来(a)使这种情况导致ICC/MSVC上的错误或(b)使用gcc/clang将它们减少到警告。我尝试了-fpermissive
与gcc,但这似乎没有帮助。
对于额外的积分,我也很好奇这个简单标量初始化错误背后的基本原理-我可以看到为什么跳过构造函数可能会有问题,但是在上面的例子中初始化
int
似乎不像它可能是一个问题,并且简单地将定义+初始化拆分为定义+赋值使错误消失?将警告视为错误的MSVC标志是/we n
,其中n
是警告的编号。
例如,
/we4326
将警告编号C4326标记为错误。