17 ms·

Should I Use Signed or Unsigned Ints? (Part 2)

61 points by robertelder 11y ago

hyperliner 11y ago
Too many problems with unsigned. Stick with signed. https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Integer_Types https://google-styleguide.googlecode.com/svn/trunk/cppguide....
- lifthrasiir 11y ago
  Or rather, too many problems with C/C++'s treatment of unsigned.
- faehnrich 11y ago
  The book "Expert C Programming" also says stick with signed, use unsigned for bitfields or binary masks. This post says unsigned for bitwise or modulo, so basically unsigned when expecting the value to be bits in a machine instead of a number.
- wnoise 11y ago
  That's funny since signed over/underflow isn't defined, while unsigned is.
  - modeless 11y ago
    Just because it's defined didn't mean it's expected. Unsigned overflow can happen with seemingly innocent subtraction of small values.
- desdiv 11y ago
  >You should assume that an int is at least 32 bits, but don't assume that it has more than 32 bits. I thought the spec[0][1] only guarantees int to be at least 16 bits? Am I missing something here? [0] http://www.cplusplus.com/doc/tutorial/variables/ http://www.cplusplus.com/doc/tutorial/variables/ [1] http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
  - IshKebab 11y ago
    True, but in practice I think the only place you'd find a 16-bit int today is with Arduino, but that is only because it is based on an archaic architecture. All ARM and Intel chips have 32-bit ints.
- stinos 11y ago
  The argument 'google says so' is addressed by the author in part [1]: Overall their argument for avoiding unsigned integers and sample code seems surprisingly weak for a company of the caliber of Google. The most important reason to use unsigned instead of signed is not self-documentation, it is to avoid undefined behaviour. [1] http://blog.robertelder.org/signed-or-unsigned/ http://blog.robertelder.org/signed-or-unsigned/
alricb 11y ago
Honest question: Would it be possible to create a "friendly" version of signed that is actually unsigned underneath? After all, it's just bit patterns.
- Dylan16807 11y ago
  fwrapv?
- detrino 11y ago
  On modern computers, both unsigned/signed ints are just bit patterns and it's only some operations that differ. add/sub/mul/left-shift are the same, but cmp/div/right-shift differ. Look up twos-complement representation for more information.
  - Sanddancer 11y ago
    Left shift also differs. Raw shifting left can have the affect of turning a negative number positive by setting the sign bit to 0, so there's a sign maintaining left shift as well. Also, Left/Right shift of negative numbers have the opposite effect as they do with positive, with left shifting a negative number dividing and right shifting multiplying.
    - detrino 11y ago
      You are mistaken, left shift is the same for both signed and unsigned and any instance of a left shift turning a signed int into a positive number is just normal underflow.
mojuba 11y ago
One of the most annoying problems in C and C++ (and Objective-C/C++). Most of the time we deal with quantities, sizes, distances, coordinates, identifiers. Except for the latter, all others can end up in the negative space even when we think they shouldn't. Having said that, identifiers and enumerated codes should also live in the signed realm as they can get converted to other types, again, in ways we can't always predict (and result in bugs).
- cpeterso 11y ago
  I wish C++ had a better way of representing quantities, something like Pascal's or Ada's ranged integer types. I started to write a C++ template class to represent strongly-typed ints. The class grew to 100+ LOC to handle all the expect operator overloads. Then I gave up. :) C++11 gave us strongly-typed enums and the means to specify the enum's underlying size (like enum class Color : unsigned short). Why can't they give us strongly-typed ints with something like int class Fahrenheit?
  - deleted 11y ago
    [deleted]
w8rbt 11y ago
One quick side story. Years ago, when I worked in automobile systems programming, some coworkers had to bring up a CAN bus data extraction system quickly (less than a week) that worked with all of our programming tools. We used Java, C#, C, Python and C++ to capture, process and display the data to end users. To save time (due to the short schedule), they decided to store all numbers as 64 bit doubles. They reasoned that 64 bit doubles were big enough to hold any number that might come off the system controllers (some where intel, others motorola) and would simplify the design so that they could write it quickly. Some time later, we discovered an infrequent bug where occasionally, some of the CAN variables were correct, but at other times they failed sanity checks (way outside of the expected values for the specific sensor). Long story short, the issue turned-out to be that 64 bit double assumption. Sometimes there was enough space to store a large 64 bit int (if the int was 52 bits or less (IIRC)), at other times the int was too large to fit. The sign (+/-) and exponent take up 12 bits or so. The moral of the story is to use the right size (and sign) for each variable and don't assume that one size will fit all. We had to go back and correct all the bad values. That took awhile. In hindsight, they should have been given more time to design the system.
- kabdib 11y ago
  Floating point numbers are almost always a mistake. Classic howlers: "Well, we can represent almost all the values we care about." Until the day you can't. "We'll represent time with a double, with the fractional part being part of a day, and the day being an integer day number from when Somebody Famous Did Something." Until you realize that the 10AM meeting you want to put in your scheduler can't be exactly represented. "We'll put our account balances in there as floats because unlike everyone else who has done this, we know what we're doing." But you don't. And that noise you heard was a million accountants crying out in pain. You wouldn't represent a pointer as "some fraction of the amount of memory the machine has, from 0.0 to 0.9999", which is my usual retort when someone wants to smuggle a scalar or structural value in a float.
  - roel_v 11y ago
    "Floating point numbers are almost always a mistake." This. The problem is that it's almost impossible to internalize this without having first-hand experience - experience which usually takes years to accumulate. By coincidence, over the last month I had to explain the problems with floating point numbers to non-technical people on two disjoint occasions, and failed miserably each time, because the technical details are too complicated and the examples too obscure. The 'store account balance in double, let's put the remainder on our own account' parable is the only example that sort of works but then they look at you blank-faced and say 'we're not a bank'. Just venting I guess. It's the simple things in mapping real-world things to bits that trip me up the most - why is it so hard to represent 'numbers' in computers? Why is it so hard to represent 'date' in computers? Why is it so hard to represent 'locations' in computers?
amluto 11y ago
> In my case, I was designing a spec for a CPU that was intended to be as minimal as possible. The CPU would physically implement signed or unsigned atomic math operations, not both. The compiler would support the missing one (signed or unsigned) using emulation in terms of the one that was physically implemented. I find that part very strange. Here are a couple of observations: * Unsigned wrapping binary addition and two's complement addition are identical as long as you don't try to report carry or overflow. * Unsigned wrapping binary subtraction and two's complement subtraction are identical as long as you don't try to report borrow or underflow. If the goal is absolute simplicity, subtraction isn't needed at all because both cases are efficiently handled by two's complement negation (which is the same thing as calculating 0-x in an unsigned wrapping sense) followed by addition. * Unsigned wrapping binary non-widening multiplication (the usual case) and two's complement multiplication are identical. This follows from the distributive law: an n-bit two's complement negative number -x is represented as 2^n - x. If you multiply -x (a two's complement number interpreted as unsigned) by y, you end up with (2^n - x) * y, which is y2^n - xy. The first term doesn't affect the result, because its low bits are all zero. Widening multiplication is extremely useful, but implementing the unsigned version in hardware should make it fairly simple to emulate the signed version. x86 implements both. Division is nasty, especially because number theorists and C programmers disagree on what it means when negative numbers are involved. Really simple CPUs don't implement division at all, though. Finally, CPU vendors who actually implement undefined behavior are, in my opinion, nuts. Give the CPU a nice clean spec that fully defines what happens and stick to it.
- detrino 11y ago
  I found this odd too. I'd add that comparison and right shift also differ, but signed right shift does have obvious semantics: sign extension. I'd also argue that signed division has obvious semantics: round towards negative infinity, which matches the semantics of right shift with sign extension. I'm saddened that none of C/C++/x86 have native support for this kind of division, it's _always_ what I want from signed division.
- dnautics 11y ago
  >CPU vendors who actually implement undefined behavior are, in my opinion, nuts. Give the CPU a nice clean spec that fully defines what happens and stick to it. So, basically none of the IEEE floats engines in AMD, Intel, ARM, etc....
simonblack 11y ago
Use whichever works best for a particular variable. If you don't know, you haven't thought about it.
chipsy 11y ago
It really shouldn't be this false dichotomy. We could have richer specifications for the bounds of numbers and the rules used to convert their formats. It's some kind of failure of imagination to not have that when arithmetic bugs traceable back to "implementation does not match representation" are so common.
- amenghra 11y ago
  Ada got this right. For example, you can do type Day_Of_Month is range 1 .. 31;
  - jmnicolas 11y ago
    What happens when you try to pass an invalid number ? An exception is thrown ?
    - ygra 11y ago
      Yes.
- kabdib 11y ago
  Making this efficient at the machine level gets hard. Hardware engineers really want to do 32 or 64 bit add/subtract/etc. datapaths, and handling range types in pipelines is hard, so it's up to software to do anything more complicated. Suddenly you're talking half a dozen instructions to do an ADD and programmers no longer want to use your language. Efficiency is a convenient god when you're not willing to pay for being correct.
mcshicks 11y ago
One thing about two's complement representation is the representation is asymmetric, you have one more negative number, i.e. 0x8000 for a 16 bit signed number is negative (unsigned) 0x8000. So a function like absolute value if it returns a signed integer cannot handle all possible input values. I think if you do any numeric processing using fixed point arithmetic you simply need to know the range is asymmetric for two's complement rather than trying to pick a scheme like always using signed or unsigned.
- qznc 11y ago
  There is no "two's complement" in C. The representation of signed integers is implementation-defined. This is one reason why C has undefined behavior. Imho it does not make sense anymore, since practically all hardware uses two's complement these days. If the standard would declare two's complement for signed integers, then shift-left would always have defined behavior, for example.
dnautics 11y ago
if you ever have to implement a softfloat on this desert island, you're going to want unsigned ints.

61 points by robertelder 11y ago

Too many problems with unsigned. Stick with signed. https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Integer_Types https://google-styleguide.googlecode.com/svn/trunk/cppguide....

lifthrasiir 11y ago
Or rather, too many problems with C/C++'s treatment of unsigned.
faehnrich 11y ago
The book "Expert C Programming" also says stick with signed, use unsigned for bitfields or binary masks. This post says unsigned for bitwise or modulo, so basically unsigned when expecting the value to be bits in a machine instead of a number.
wnoise 11y ago
That's funny since signed over/underflow isn't defined, while unsigned is.
- modeless 11y ago
  Just because it's defined didn't mean it's expected. Unsigned overflow can happen with seemingly innocent subtraction of small values.
desdiv 11y ago
>You should assume that an int is at least 32 bits, but don't assume that it has more than 32 bits. I thought the spec[0][1] only guarantees int to be at least 16 bits? Am I missing something here? [0] http://www.cplusplus.com/doc/tutorial/variables/ http://www.cplusplus.com/doc/tutorial/variables/ [1] http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
- IshKebab 11y ago
  True, but in practice I think the only place you'd find a 16-bit int today is with Arduino, but that is only because it is based on an archaic architecture. All ARM and Intel chips have 32-bit ints.
stinos 11y ago
The argument 'google says so' is addressed by the author in part [1]: Overall their argument for avoiding unsigned integers and sample code seems surprisingly weak for a company of the caliber of Google. The most important reason to use unsigned instead of signed is not self-documentation, it is to avoid undefined behaviour. [1] http://blog.robertelder.org/signed-or-unsigned/ http://blog.robertelder.org/signed-or-unsigned/

alricb 11y ago

Honest question: Would it be possible to create a "friendly" version of signed that is actually unsigned underneath? After all, it's just bit patterns.

Dylan16807 11y ago
fwrapv?
detrino 11y ago
On modern computers, both unsigned/signed ints are just bit patterns and it's only some operations that differ. add/sub/mul/left-shift are the same, but cmp/div/right-shift differ. Look up twos-complement representation for more information.
- Sanddancer 11y ago
  Left shift also differs. Raw shifting left can have the affect of turning a negative number positive by setting the sign bit to 0, so there's a sign maintaining left shift as well. Also, Left/Right shift of negative numbers have the opposite effect as they do with positive, with left shifting a negative number dividing and right shifting multiplying.
  - detrino 11y ago
    You are mistaken, left shift is the same for both signed and unsigned and any instance of a left shift turning a signed int into a positive number is just normal underflow.

mojuba 11y ago

One of the most annoying problems in C and C++ (and Objective-C/C++). Most of the time we deal with quantities, sizes, distances, coordinates, identifiers. Except for the latter, all others can end up in the negative space even when we think they shouldn't. Having said that, identifiers and enumerated codes should also live in the signed realm as they can get converted to other types, again, in ways we can't always predict (and result in bugs).

cpeterso 11y ago
I wish C++ had a better way of representing quantities, something like Pascal's or Ada's ranged integer types. I started to write a C++ template class to represent strongly-typed ints. The class grew to 100+ LOC to handle all the expect operator overloads. Then I gave up. :) C++11 gave us strongly-typed enums and the means to specify the enum's underlying size (like enum class Color : unsigned short). Why can't they give us strongly-typed ints with something like int class Fahrenheit?
- deleted 11y ago
  [deleted]

w8rbt 11y ago

One quick side story. Years ago, when I worked in automobile systems programming, some coworkers had to bring up a CAN bus data extraction system quickly (less than a week) that worked with all of our programming tools. We used Java, C#, C, Python and C++ to capture, process and display the data to end users. To save time (due to the short schedule), they decided to store all numbers as 64 bit doubles. They reasoned that 64 bit doubles were big enough to hold any number that might come off the system controllers (some where intel, others motorola) and would simplify the design so that they could write it quickly. Some time later, we discovered an infrequent bug where occasionally, some of the CAN variables were correct, but at other times they failed sanity checks (way outside of the expected values for the specific sensor). Long story short, the issue turned-out to be that 64 bit double assumption. Sometimes there was enough space to store a large 64 bit int (if the int was 52 bits or less (IIRC)), at other times the int was too large to fit. The sign (+/-) and exponent take up 12 bits or so. The moral of the story is to use the right size (and sign) for each variable and don't assume that one size will fit all. We had to go back and correct all the bad values. That took awhile. In hindsight, they should have been given more time to design the system.

kabdib 11y ago
Floating point numbers are almost always a mistake. Classic howlers: "Well, we can represent almost all the values we care about." Until the day you can't. "We'll represent time with a double, with the fractional part being part of a day, and the day being an integer day number from when Somebody Famous Did Something." Until you realize that the 10AM meeting you want to put in your scheduler can't be exactly represented. "We'll put our account balances in there as floats because unlike everyone else who has done this, we know what we're doing." But you don't. And that noise you heard was a million accountants crying out in pain. You wouldn't represent a pointer as "some fraction of the amount of memory the machine has, from 0.0 to 0.9999", which is my usual retort when someone wants to smuggle a scalar or structural value in a float.
- roel_v 11y ago
  "Floating point numbers are almost always a mistake." This. The problem is that it's almost impossible to internalize this without having first-hand experience - experience which usually takes years to accumulate. By coincidence, over the last month I had to explain the problems with floating point numbers to non-technical people on two disjoint occasions, and failed miserably each time, because the technical details are too complicated and the examples too obscure. The 'store account balance in double, let's put the remainder on our own account' parable is the only example that sort of works but then they look at you blank-faced and say 'we're not a bank'. Just venting I guess. It's the simple things in mapping real-world things to bits that trip me up the most - why is it so hard to represent 'numbers' in computers? Why is it so hard to represent 'date' in computers? Why is it so hard to represent 'locations' in computers?

amluto 11y ago

> In my case, I was designing a spec for a CPU that was intended to be as minimal as possible. The CPU would physically implement signed or unsigned atomic math operations, not both. The compiler would support the missing one (signed or unsigned) using emulation in terms of the one that was physically implemented. I find that part very strange. Here are a couple of observations: * Unsigned wrapping binary addition and two's complement addition are identical as long as you don't try to report carry or overflow. * Unsigned wrapping binary subtraction and two's complement subtraction are identical as long as you don't try to report borrow or underflow. If the goal is absolute simplicity, subtraction isn't needed at all because both cases are efficiently handled by two's complement negation (which is the same thing as calculating 0-x in an unsigned wrapping sense) followed by addition. * Unsigned wrapping binary non-widening multiplication (the usual case) and two's complement multiplication are identical. This follows from the distributive law: an n-bit two's complement negative number -x is represented as 2^n - x. If you multiply -x (a two's complement number interpreted as unsigned) by y, you end up with (2^n - x) * y, which is y2^n - xy. The first term doesn't affect the result, because its low bits are all zero. Widening multiplication is extremely useful, but implementing the unsigned version in hardware should make it fairly simple to emulate the signed version. x86 implements both. Division is nasty, especially because number theorists and C programmers disagree on what it means when negative numbers are involved. Really simple CPUs don't implement division at all, though. Finally, CPU vendors who actually implement undefined behavior are, in my opinion, nuts. Give the CPU a nice clean spec that fully defines what happens and stick to it.

detrino 11y ago
I found this odd too. I'd add that comparison and right shift also differ, but signed right shift does have obvious semantics: sign extension. I'd also argue that signed division has obvious semantics: round towards negative infinity, which matches the semantics of right shift with sign extension. I'm saddened that none of C/C++/x86 have native support for this kind of division, it's _always_ what I want from signed division.
dnautics 11y ago
>CPU vendors who actually implement undefined behavior are, in my opinion, nuts. Give the CPU a nice clean spec that fully defines what happens and stick to it. So, basically none of the IEEE floats engines in AMD, Intel, ARM, etc....

simonblack 11y ago

Use whichever works best for a particular variable. If you don't know, you haven't thought about it.

chipsy 11y ago

It really shouldn't be this false dichotomy. We could have richer specifications for the bounds of numbers and the rules used to convert their formats. It's some kind of failure of imagination to not have that when arithmetic bugs traceable back to "implementation does not match representation" are so common.

amenghra 11y ago
Ada got this right. For example, you can do type Day_Of_Month is range 1 .. 31;
- jmnicolas 11y ago
  What happens when you try to pass an invalid number ? An exception is thrown ?
  - ygra 11y ago
    Yes.
kabdib 11y ago
Making this efficient at the machine level gets hard. Hardware engineers really want to do 32 or 64 bit add/subtract/etc. datapaths, and handling range types in pipelines is hard, so it's up to software to do anything more complicated. Suddenly you're talking half a dozen instructions to do an ADD and programmers no longer want to use your language. Efficiency is a convenient god when you're not willing to pay for being correct.

mcshicks 11y ago

One thing about two's complement representation is the representation is asymmetric, you have one more negative number, i.e. 0x8000 for a 16 bit signed number is negative (unsigned) 0x8000. So a function like absolute value if it returns a signed integer cannot handle all possible input values. I think if you do any numeric processing using fixed point arithmetic you simply need to know the range is asymmetric for two's complement rather than trying to pick a scheme like always using signed or unsigned.

qznc 11y ago
There is no "two's complement" in C. The representation of signed integers is implementation-defined. This is one reason why C has undefined behavior. Imho it does not make sense anymore, since practically all hardware uses two's complement these days. If the standard would declare two's complement for signed integers, then shift-left would always have defined behavior, for example.

dnautics 11y ago

if you ever have to implement a softfloat on this desert island, you're going to want unsigned ints.