R..*_*R.. 15 c 64-bit integer-promotion
直到最近,我还是考虑过大多数系统实现者/供应商的决定,int即使在64位机器上保持简单的32位也是一种权宜之计.随着现代C99固定大小的类型(int32_t和uint32_t等)的需要为了有每个大小为8,16,32的一个标准的整数类型,和64大多消失,并且它似乎是int也可以同样进行64位.
然而,intC 中普通大小的最大实际结果来自于C基本上没有小于int类型的算术.特别是,如果int大于32位,则对uint32_t值的任何算术运算的结果都具有类型signed int,这相当令人不安.
这是否是int在实际实现中永久固定为32位的一个很好的理由？我倾向于说是的.在我看来,uint32_t当int大于32位时,可能存在大量的使用.即使应用一元减号或按位补码运算符也会变得危险,除非你再次使用uint32_t.
当然,同样的问题也适用于uint16_t和uint8_t当前实现,但大家似乎都知道,并用于把它们当作"小-于─ int"类型.
正如你所说,我认为促销规则确实是杀手锏.uint32_t然后会促进int并且突然之间你已经签署了几乎所有人都希望未签名的算术.
这将主要隐藏在你只进行算术并分配回来的地方uint32_t.但是在与常数进行比较的地方它可能是致命的.我不知道,在没有进行显式演员的情况下依赖于这种比较的代码是否合理.像这样的强制转换(uint32_t)1会变得相当繁琐.我个人至少总是使用后缀U作为我想要无符号的常量,但这已经不像我想的那样可读.
还要记住,uint32_t不保证存在等.不是uint8_t.执行该操作是POSIX的扩展.因此,在这种意义上,作为一种语言的C远远不能实现这一目标.
"合理的代码"......
嗯...关于开发的事情是,你编写并修复它然后它起作用......然后你就停止了!
也许你已经被烧了很多,所以你可以保持在某些特征的安全范围内,也许你没有以这种特殊的方式被烧毁,所以你没有意识到你依赖的东西 -变化
或者甚至你依赖于一个bug.
在旧版的Mac 68000编译器中,int为16位,长度为32.但即便如此,大多数现存的C代码假定int为32,因此您在新闻组中找到的典型代码将无效.(哦,Mac没有printf,但我离题了.)
所以,我得到的是,是的,如果你改变了什么,那么有些事情就会破裂.
| 归档时间： |
|
| 查看次数： |
641 次 |
| 最近记录： |