如何抑制“note C6311”在微软C编译器中？
在这个最大限幅源示例中，清单常量 FOOBAR 被重新定义。这是故意的，并且在实际案例中有额外的代码来使用每个定义。
添加编译指示是为了消除警告消息，但随后出现了一条注释，而我似乎找不到消除该注释的方法。
我已经能够将此特定源修改为 #define 之间的 #undef，但我想知道是否有一种方法可以在不需要 的情况下抑制注释>#undef，因为有多个常量以相同的方式处理。
#pragma warning( disable : 4005 ) // 'identifier' : macro redefinition
#define FOOBAR FOO
#define FOOBAR BAR
编译器横幅和输出如下
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
message.c
message.c(3) : note C6311: message.c(2) : see previous definition of 'FOOBAR'
In this maximally clipped source example, the manifest constant FOOBAR is being redefined. This is deliberate, and there is extra code in the live case to make use of each definition.
The pragma was added to get rid of a warning message, but then a note appeared, and I don't seem to find a way to get rid of the note.
I've been able to modify this particular source to #undef between the #define, but I would like to know if there's a way to inhibit the note without requiring #undef, since there are multiple constants being handled the same way.
#pragma warning( disable : 4005 ) // 'identifier' : macro redefinition
#define FOOBAR FOO
#define FOOBAR BAR
The compiler banner and output are as follows
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
message.c
message.c(3) : note C6311: message.c(2) : see previous definition of 'FOOBAR'
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除非新定义与当前定义相同，否则不允许重新定义宏（如果重新定义宏并且新定义与当前定义不同，则程序实际上是格式错误的）。
在这种情况下，在重新定义宏之前先
#undef进行宏定义是正确的做法：请注意，即使当前没有宏名称，您也可以使用
#undef已定义，因此没有理由在使用#undef之前测试宏是否已使用#ifdef定义。You are not allowed to redefine a macro unless the new definition is identical to the current definition (if you redefine a macro and the new definition is different than the current definition, the program is actually ill-formed).
#undefing the macro before redefining it is the correct thing to do in this case:Note that you are allowed to use
#undefeven if a macro name isn't currently defined, so there's no reason to test whether the macro is defined using#ifdefbefore using#undefon it.