VS2012无符号求反 [英] VS2012 unsigned negate

问题描述

在应该是相当便携的代码中，在许多人，许多环境项目中，我必须处理一个问题，否定 unsigned int 相同的问题在其他地方否定 std :: size_t ）。

In code that is supposed to be quite portable, in a many person, many environment project, I have to deal with a problem with code that negates unsigned int (and same problem in other places negating std::size_t).

目的是创建该值的加性逆（模MAX_VAL + 1，其中MAX_VAL是类型的最大值），我发现有关此主题的其他问题这是标准的指定行为。

The intent is to create the additive inverse of that value (modulo MAX_VAL+1 where MAX_VAL is the max value of the type) and I found other questions on this topic confirm that is the standard specified behavior.

VS2012，（有编译时选项我不能轻易学习）调用一行错误。访问该环境的开发人员将 -U 更改为 -1 * U ，在该环境中编译。我对这种变化有一个低的看法，我不满意的工作，我需要通过可移植性测试，改变代码，第一次是正确的。

VS2012, (with compile time options I cannot easily learn) calls that line an error. The developer, with access to that environment, changed -U to -1*U, which compiles in that environment. I have a low opinion of that change and I'm not happy with the work I would need to go through to portability test that change to code that was correct in the first place.

我希望有一些#pragma，它会告诉VS2012允许 -U 。我期望这将更容易找到比探索任何后果 -1 * U （超出事实，我认为 -1 * U 是令人厌恶的）。

I expect there is some #pragma, which will tell VS2012 to allow -U to have its standards defined meaning. I expect that will be easier to find than exploring any consequences of -1*U (beyond the fact that I think -1*U is disgusting).

但我希望得到一些语言律师和/或VS2012古茹的意见，之前尝试任何。

But I'm hoping to get some language lawyer and/or VS2012 guru opinions before trying any of that.

编辑，我应该链接相关的以前的答案：

Edit, I should have linked the relevant previous answer: What should happen to the negation of a size_t (i.e. `-sizeof(struct foo)`))?

我相信原来的代码是正确的基于这个答案。我想知道如何使VS2012相信代码是正确的。

I believe the original code is correct based on that answer. I want to know how to make VS2012 believe the code is correct.

错误讯息是：

错误C4146： unsigned type，result still unsigned

error C4146: unary minus operator applied to unsigned type, result still unsigned

推荐答案

#pragma warning 4146）// VS2012一元减运算符应用于无符号类型

我没有试图挖掘解决方案层次结构将不安全的警告转换为讨厌的错误。在本地的源代码中，在 unsigned 或 std :: size_t 被正确否定的几个地方， #pragma 作为一个注释是相当合理的，使任何人类代码审查人员或MS编译器明确否定无符号是真正的故意。

I didn't try to dig up what ill advised option someone added somewhere in the solution hierarchy to convert that unsound warning into a nasty error. Locally in the source code, in the several places where an unsigned or a std::size_t is correctly negated, the #pragma is quite reasonable as a comment to make it clear to any human code reviewer or MS compiler that negating an unsigned really was intentional.

我测试， #pragma 真的把它从错误转换为静音。

I tested, that #pragma really does convert it all the way down from error to silent.

在项目风格上，编译器版本在注释警告禁用时只告诉哪个编译器/版本触发决定添加 #pragma 。它不打算给出任何提示，广泛或狭窄（其他编译器或版本）的问题可能是。

As a matter of project style, the compiler version in the comment on a warning disable tells only which compiler/version triggered the decision to add the #pragma. It is not intended to give any hint at how broad or narrow (other compilers or versions) the issue might be.

如果我在控制这方面的所有方面，我可能会认为命令行选项将这个警告变成一个错误是不好的建议，修复命令行比源代码（并值得所有额外的努力找到的地方，无论stupid选项注入到命令行）。但事实上，我对这条命令行没有影响。我可以对这些源文件中做什么做出最终决定，以补偿关于命令行的错误决定。我不能影响我可能认为是关于命令行的错误决定。

If I were in control of all aspects of this, I might decide that the command line option turning this warning into an error is so ill advised that it would be better to fix the command line than the source code (and worth all the extra effort to find the place whatever stupid option was injected into the command line). But in fact, I have no influence over that command line. I can make the final decision on what to do in these source files to compensate for bad decisions regarding the command line. I can't influence whatever I might consider to be bad decisions regarding the command line.

这篇关于VS2012无符号求反的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！