在一个应该是非常便携的代码中，在很多人，很多环境项目中，我必须处理一个否定unsigned int的代码问题（在其他地方同样的问题否定{{1} }）。
目的是创建该值的加法逆（模MAX_VAL + 1，其中MAX_VAL是该类型的最大值），我发现关于该主题的其他问题确认这是标准的指定行为。
VS2012，（编译时选项，我不能轻易学习）调用该行错误。有权访问该环境的开发人员将std::size_t更改为-U，并在该环境中进行编译。我对这种变化的看法很低，我对我需要进行的可移植性测试所需的工作感到不满意，该测试改为首先正确的代码。
我希望有一些#pragma，它会告诉VS2012允许-1*U定义其标准含义。我希望这比探索-U的任何后果更容易找到（除了我认为-1*U令人作呕的事实之外）。
但我希望在尝试任何此类语言之前获得一些语言律师和/或VS2012大师的意见。
编辑，我应该链接相关的先前答案： What should happen to the negation of a size_t (i.e. `-sizeof(struct foo)`))?
我认为基于该答案的原始代码是正确的。我想知道如何让VS2012相信代码是正确的。
错误消息是：
-1*U
答案 0 :(得分：2)
#pragma warning (disable : 4146) // VS2012 unary minus operator applied to unsigned type
我没有尝试挖掘某人在解决方案层次结构中添加的错误选项，将不健全的警告转换为令人讨厌的错误。在源代码的本地位置，在unsigned或std::size_t被正确否定的几个地方，#pragma作为评论非常合理，以便向任何人类代码审核者或否定无符号的MS编译器确实是故意的。
我测试过，#pragma确实将它从错误一直转换为无声。
作为项目样式的问题，警告禁用注释中的编译器版本仅告知哪个编译器/版本触发了添加#pragma的决定。它无意暗示问题可能有多宽或多窄（其他编译器或版本）。
如果我控制了这方面的所有方面，我可能会认为命令行选项将此警告转换为错误是不明智的，建议修复命令行比源代码更好（并且值得所有找到这个地方的额外工作，无论愚蠢的选项被注入命令行）。但实际上，我对该命令行没有影响力。我可以最终决定在这些源文件中做什么来补偿有关命令行的错误决定。我无法影响我认为对命令行做出的错误决定。