ES.46: Avoid lossy (narrowing, truncating) arithmetic conversions
ES.46:避免有损(窄化,截短)算数转换
Reason(原因)
A narrowing conversion destroys information, often unexpectedly so.
窄化转换破坏信息,通常不是期待的动作。
Example, bad(反面示例)
A key example is basic narrowing:
主要的示例说明窄化的基本情况:
Note(注意)
The guidelines support library offers a narrow_cast operation for specifying that narrowing is acceptable and a narrow ("narrow if") that throws an exception if a narrowing would throw away information:
准则支持库提供了一个narrow_cast操作,可以用来表明窄化是可接受的;一个narrow(“如果发生窄化转换”)操作,它可以在丢失了任何信息时抛出异常。
We also include lossy arithmetic casts, such as from a negative floating point type to an unsigned integral type:
这两个操作也可以处理有损算数转换,例如从负浮点数转换为无符号整数的情况。
Enforcement(实施建议)
A good analyzer can detect all narrowing conversions. However, flagging all narrowing conversions will lead to a lot of false positives. Suggestions:
实现良好的代码分析器可以检出所有的窄化转换。但是标识所有的窄化转换会导致大量的假阳性结果。建议:
- Flag all floating-point to integer conversions (maybe only float->char and double->int. Here be dragons! we need data).
- 标记所有浮点数到整数的转换(或许只需要标记float到char和double到int。 都有可能! 我们需要数据)
- Flag all long->char (I suspect int->char is very common. Here be dragons! we need data).
- 标记所有long到char的转换(我怀疑int到char的转换很普遍。都有可能! 我们需要数据)
- Consider narrowing conversions for function arguments especially suspect.
- 函数参数的窄化转换尤其可疑。
原文链接
觉得本文有帮助?欢迎点赞并分享给更多的人。
阅读更多更新文章,请关注微信公众号【面向对象思考】
















