一个人的补足是一个现实世界的问题，还是一个历史问题？
另一个问题询问如何确定 C 中的奇数/偶数，并且惯用的 (x & 1) 方法被正确标记为损坏 < a href="http://en.wikipedia.org/wiki/Signed_number_representations#Ones.27_complement" rel="noreferrer">基于补码的系统，这是 C 标准允许的。
系统真的存在于计算机博物馆之外的“现实世界”中吗？ 我从 20 世纪 70 年代就开始编码，而且我很确定我从未遇到过这样的野兽。
是否有人真正为这样的系统开发或测试代码？ 如果没有，我们是否应该担心这些事情，或者我们应该将它们与Room 101一起放入纸带和打孔卡...？
Another question asked about determining odd/evenness in C, and the idiomatic (x & 1) approach was correctly flagged as broken for one's complement-based systems, which the C standard allows for.
Do systems really exist in the 'real world' outside of computer museums? I've been coding since the 1970's and I'm pretty sure I've never met such a beast.
Is anyone actually developing or testing code for such a system? And, if not, should we worry about such things or should we put them into Room 101 along with paper tape and punch cards...?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我在遥测领域工作，我们的一些客户拥有仍然使用 1 补码的旧模数转换器。 前几天我只需要编写代码将 1 的补码转换为 2 的补码以进行补偿。
所以是的，它仍然存在（但你不会经常遇到它）。
I work in the telemetry field and we have some of our customers have old analog-to-digital converters that still use 1's complement. I just had to write code the other day to convert from 1's complement to 2's complement in order to compensate.
So yes, it's still out there (but you're not going to run into it very often).
这一切都取决于了解你的根源。
是的，这在技术上是一种古老的技术，我可能会按照其他人在该问题中建议的方式进行操作，并使用模 (%) 运算符来确定奇数或偶数。
但了解什么是 1 补码（或 2 补码）总是一件好事。 无论您是否使用过它们，您的 CPU 一直在处理这些事情。 所以理解这个概念永远不会有什么坏处。 现在，现代系统使您通常不必担心类似的事情，因此它在某种程度上已成为编程 101 课程的主题。 但你必须记住，有些人实际上仍然会在“现实世界”中使用它......例如，与流行的看法相反，有些人仍然使用汇编！不多，但直到 CPU 出现可以理解原始的 C# 和 Java，有人仍然需要理解这些东西。
哎呀，你永远不知道什么时候你会发现自己在做一些实际上需要执行二进制数学的事情，而 1 的补码可能会派上用场。
This all comes down to knowing your roots.
Yes, this is technically an old technique and I would probably do what other people suggested in that question and use the modulo (%) operator to determine odd or even.
But understanding what a 1s complement (or 2s complement) is always a good thing to know. Whether or not you ever use them, your CPU is dealing with those things all of the time. So it can never hurt to understand the concept. Now, modern systems make it so you generally never have to worry about things like that so it has become a topic for Programming 101 courses in a way. But you have to remember that some people actually would still use this in the "real world"... for example, contrary to popular belief there are people who still use assembly! Not many, but until CPUs can understand raw C# and Java, someone is going to still have to understand this stuff.
And heck, you never know when you might find your self doing something where you actually need to perform binary math and that 1s complement could come in handy.
我在 80 年代使用的 CDC Cyber 18 是一台 1s 补码机器，但那是近 30 年前的事了，从那以后我就再也没有见过它（不过，那也是我最后一次在非 PC 上工作）
The CDC Cyber 18 I used back in the '80 was a 1s complement machine, but that's nearly 30 years ago, and I haven't seen one since (however, that was also the last time I worked on a non-PC)
RFC 791 p.14 将 IP 标头校验和定义为：
因此，在现实世界中，发送的每个 IP 数据包中仍然大量使用补码。 :)
RFC 791 p.14 defines the IP header checksum as:
So one's complement is still heavily used in the real world, in every single IP packet that is sent. :)
我决定找一个。 Unisys ClearPath 系统有一个 ANSI C 编译器（是的，他们称之为“美国国家标准 C”，甚至 PDF 文档的最后更新也是在 2013 年。该文档可在 在线;
那里签名类型都使用补码表示，具有以下属性：
值得注意的是，它默认也支持非一致的
unsigned int和unsigned long，范围从0 ... 2³⁶ - 2，但可以使用编译指示更改为0 ... 2³⁶ - 1。I decided to find one. The Unisys ClearPath systems have an ANSI C compiler (yes they call it "American National Standard C" for which even the PDF documentation was last updated in 2013. The documentation is available online;
There the signed types are all using one's complement representation, with the following properties:
Remarkably, it also by default supports non-conforming
unsigned intandunsigned long, which range from0 ... 2³⁶ - 2, but can be changed to0 ... 2³⁶ - 1with a pragma.我从来没有遇到过补码系统，而且我和你一样一直在编码。
但我确实遇到了 9 的补码系统——HP-41c 计算器的机器语言。 我承认这可以被认为是过时的，而且我认为他们从来没有针对这些的 C 编译器。
I've never encountered a one's complement system, and I've been coding as long as you have.
But I did encounter a 9's complement system -- the machine language of a HP-41c calculator. I'll admit that this can be considered obsolete, and I don't think they ever had a C compiler for those.
去年的某个时候，我们卸下了最后一台 1960 年代的 Honeyboxen，这使它成为我们现场最古老的机器。 这是二进制补码。 这并不是说了解或意识到自己的互补是一件坏事。 只是，无论他们在工作中让您进行多少计算机考古工作，您今天可能永远不会遇到补码问题。
您在整数方面更有可能遇到的问题是 endian 问题（我正在寻找在您PDP）。 此外，您还会遇到更多“现实世界”（即今天）的问题 浮动 点 格式 与整数格式不同。
We got off our last 1960's Honeyboxen sometime last year, which made it our oldest machine on site. It was two's complement. This isn't to say knowing or being aware of one's complement is a bad thing. Just, You will probably never run into one's complement issues today, no matter how much computer archeology they have you do at work.
The issues you are more likely to run into on the integer side are endian issues (I'm looking at you PDP). Also, you'll run into more "real world" (i.e. today) issues with floating point formats than you will integer formats.
有趣的是，人们在 comp.std.c 1993 年，没有人能指出当时使用过的补码机。
所以，是的，我认为我们可以自信地说，一个人的补语属于我们历史的一个黑暗角落，几乎已经死了，不再是一个问题。
Funny thing, people asked that same question on comp.std.c in 1993, and nobody could point to a one's complement machine that had been used back then.
So yes, I think we can confidently say that one's complement belongs to a dark corner of our history, practically dead, and is not a concern anymore.
是的，还在用。 它甚至用于现代英特尔处理器。 来自英特尔® 64 和 IA- 32 Architectures 软件开发人员手册 2A，第 3-8 页：
Yes, it still used. Its even used in modern Intel processors. From Intel® 64 and IA-32 Architectures Software Developer’s Manual 2A, page 3-8: