Signed Integers Are Two’s Complement
open-std.org
Signed Integers Are Two’s Complement
1–10 of 126 posts
Re: Signed Integers Are Two’s Complement
#2Re: Signed Integers Are Two’s Complement
#3Re: Signed Integers Are Two’s Complement
#4In April, the author of this proposal said on Twitter that the C++ standards committee agreed to this proposal for C++20: https://twitter.com/jfbastien/status/989242576598327296?lang...
Re: Signed Integers Are Two’s Complement
#5I'm curious why some old architectures didn't use two's complement for signed numbers. What advantage did one's complement or signed magnitude have over two's complement?
Re: Signed Integers Are Two’s Complement
#6I'm curious why some old architectures didn't use two's complement for signed numbers. What advantage did one's complement or signed magnitude have over two's complement?
Re: Signed Integers Are Two’s Complement
#7What they could have done is made it implementation defined, like sizeof(int), which depends on the implementation (hardware) but on the other hand isn't undefined behavior (so on x86/amd4 sizeof(int) will always be equal to 4).
Re: Signed Integers Are Two’s Complement
#8The real issue isn't that C doesn't have a standard int overflow, but that it's undefined. What they could have done is made it implementation defined , like sizeof(int), which depends on the implementation (hardware) but on the other hand isn't undefined behavior (so on x86/amd4 sizeof(int) will always be equal to 4).
Nothing is stopping your C compiler from making the guarantee sizeof(int)=4 on x86/amd64.
Re: Signed Integers Are Two’s Complement
#9I'm curious why some old architectures didn't use two's complement for signed numbers. What advantage did one's complement or signed magnitude have over two's complement?
Negabinary operations are extremely simple and elegant. Like 2s complement and 1s complement, it suffers from asymmetry in its range, though even more so.
Re: Signed Integers Are Two’s Complement
#10The real issue isn't that C doesn't have a standard int overflow, but that it's undefined. What they could have done is made it implementation defined , like sizeof(int), which depends on the implementation (hardware) but on the other hand isn't undefined behavior (so on x86/amd4 sizeof(int) will always be equal to 4).
> on x86/amd4 sizeof(int) will always be equal to 4 Nothing is stopping your C compiler from making the guarantee sizeof(int)=4 on x86/amd64.