另一个问题是关于确定C中的奇数/偶数,并且惯用(x&1)方法被正确地标记为基于补体的系统被破坏,C标准允许.
系统真的存在于计算机博物馆之外的"现实世界"吗？自1970年代以来,我一直在编码,我很确定我从来没有见过这样的野兽.
有人在为这样的系统开发或测试代码吗？如果没有,我们是否应该担心这些事情,还是应该将它们与纸带和打卡一起放入101室？
我在遥测领域工作,我们的一些客户拥有旧的模数转换器,仍然使用1的补码.我不得不在前几天编写代码,将1的补码转换为2的补码,以便进行补偿.
所以,是的,它仍然在那里(但你不会经常遇到它).
这一切都归结为了解你的根源.
是的,这在技术上是一种旧技术,我可能会做其他人在该问题中建议的内容,并使用模数(%)运算符来确定奇数或偶数.但是要了解1s补码(或2s补码)总是一件好事.无论你是否曾经使用它们,你的CPU总是在处理这些事情.因此理解这个概念永远不会有害.现在,现代系统使得你通常不必担心这样的事情,因此它已经成为编程101课程的主题.但你必须记住,有些人实际上仍会在"现实世界"中使用它......例如,与流行的看法相反,有些人仍在使用汇编! 并不多,但在CPU能够理解原始C#和Java之前,有人仍然需要了解这些东西.
哎呀,你永远都不知道什么时候你可能会发现你的自己做了一些你真正需要进行二进制数学运算的东西,并且1s补码可以派上用场.
RFC 791第14页将IP头校验和定义为:
校验和字段是报头中所有16位字的一个补码和的16位补码.出于计算校验和的目的,校验和字段的值为零.
因此,在现实世界中,在发送的每个IP数据包中仍然大量使用补充.:)
我在80年代使用的CDC Cyber 18是1s补充机器,但是差不多30年前,我从未见过一台(但是,这也是我最后一次在非PC上工作)
我从来没有遇到过一个人的补充系统,只要你有,我就一直在编码.
但我确实遇到了9的补充系统 - HP-41c计算器的机器语言.我承认这可以被认为是过时的,我不认为他们曾经有过这样的C编译器.
去年的某个时候,我们使用了1960年代的Honeyboxen,这使它成为我们现场最古老的机器.这是两个补充.这并不是说知道或意识到一个人的补充是一件坏事.只是,无论你在工作中做多少计算机考古,你今天可能永远不会碰到一个补充问题.
你更有可能在整数方面遇到的问题是endian问题(我在看你PDP).此外,你会碰到更多的"真实世界"(即今天)问题进行浮动 点 格式比你的整数格式.
有趣的是,人们在1993年的comp.std.c 上问同样的问题,没有人能指出当时使用过的一台补充机器.
所以,是的,我认为我们可以自信地说,一个人的补充属于我们历史的一个黑暗角落,几乎死了,不再是一个问题了.
我决定找一个.Unisys ClearPath系统有一个ANSI C编译器(是的,他们称之为"美国国家标准C",甚至PDF文档最后一次更新于2013年.该文档可在线获取 ;
签名类型都使用一个补码表示,具有以下属性:
Type | Bits | Range ---------------------+------+----------------- signed char | 9 | -2?+1 ... 2?-1 signed short | 18 | -2¹?+1 ... 2¹?-1 signed int | 36 | -2³?+1 ... 2³?-1 signed long int | 36 | -2³?+1 ... 2³?-1 signed long long int | 72 | -2?¹+1 ... 2?¹-1
值得注意的是,它默认情况下也支持不符合unsigned int和unsigned long,范围从0 ... 2³? - 2,但可以0 ... 2³? - 1使用pragma 更改为.
京公网安备 11010802040832号 | 京ICP备19059560号-6 