Signed and Unsigned
It specifies wether or not they use the sign bit. That means you can assign negative values to the signed one, but an unsigned integer can store positive values with "double" the range.
eg: 8 bit integer
unsigned 0 to 255
signed -127 to +127
eg: 8 bit integer
unsigned 0 to 255
signed -127 to +127
Signed integers can be negative. Unsigned integers can't. (If you try to assign an unsigned integer a negative value it'll "wrap around" and be a really high positive value). Unsigned integers also get to use an extra bit for storing slightly larger numbers than a signed integer, because in a signed integer that bit is used to store the sign of the integer.
Personally, I don't use them but you could use them internally for variables you know will never be negative to reinforce that fact. Also, if you had for example a function f(int x) where the only valid values of x are 0 - 255, instead of checking if(x < 0 || x > 255), if you had f(unsigned int x) you would only have to check if(x > 255), since if x was passed a negative value it'll wrap around to the really high positive value as mentioned previously.
EDIT: Hmm, beaten over the head by 3 posts :0
Personally, I don't use them but you could use them internally for variables you know will never be negative to reinforce that fact. Also, if you had for example a function f(int x) where the only valid values of x are 0 - 255, instead of checking if(x < 0 || x > 255), if you had f(unsigned int x) you would only have to check if(x > 255), since if x was passed a negative value it'll wrap around to the really high positive value as mentioned previously.
EDIT: Hmm, beaten over the head by 3 posts :0
Quote:Original post by Vampyre_Dark
signed -127 to +127
Nitpick: -128 to 127.
This is because binary numbers hold a power of 2 different values, and there's no reason to allow the representation of both +0 and -0.
Feel free to test it yourself:
#include <cassert>int main ( void ){ signed char positive128 = 128; signed char negative128 = -128; signed char negative129 = 129; assert( positive128 < 0 ); //due to wrap around assert( negative128 < 0 ); //dosn't wrap around assert( negative129 > 0 ); //due to wrap around}
okay, so ditto above posts.
One thing you'll want to watch out for with unsigneds is decrementing loop counts. In the past I've had to deal with a very common yet bizzare problem that takes a general form:
for(unsigned int i = n; i > 0; i-- )
{ ... }
DON'T do this. The compiler thinks the test case resolves to a == test against zero, which may not be accurate. If you're using a decrementing loop, don't use unsigned's without examining the assembly output to make sure your case is safe.
One thing you'll want to watch out for with unsigneds is decrementing loop counts. In the past I've had to deal with a very common yet bizzare problem that takes a general form:
for(unsigned int i = n; i > 0; i-- )
{ ... }
DON'T do this. The compiler thinks the test case resolves to a == test against zero, which may not be accurate. If you're using a decrementing loop, don't use unsigned's without examining the assembly output to make sure your case is safe.
Quote:Original post by ajas95
okay, so ditto above posts.
One thing you'll want to watch out for with unsigneds is decrementing loop counts. In the past I've had to deal with a very common yet bizzare problem that takes a general form:
for(unsigned int i = n; i > 0; i-- )
{ ... }
DON'T do this. The compiler thinks the test case resolves to a == test against zero, which may not be accurate. If you're using a decrementing loop, don't use unsigned's without examining the assembly output to make sure your case is safe.
Are you sure you wern't smoking anything, and if not, can I have some? :-p.
Kidding aside, that's sane code - it will run the loop with i = N to 1. It'd be an extremely major compiler bug if it didn't. You DO have problems for i >= 0, which is probably what you meant (since this evaluates the same as i < 0, which can never occur for an unsigned). The ugly (but safe) solution to this is to write something like: i > type_of_i(-1).
MM, you're surely correct. It was code that had >= in the test expression. But I would never have been able to find it if I didn't know how to read the assembly.
I assumed that because I could do:
I guess the crash makes sense... name me an unsigned int which is NOT >= 0 :)
[edit: tenses]
I assumed that because I could do:
for(unsigned int i = 0; i < total; i++)...I could do:for(unsigned int i = total - 1; i >= 0; i--)...I guess the crash makes sense... name me an unsigned int which is NOT >= 0 :)
[edit: tenses]
Well, at least gcc issues a warning if a loop condition is always true due to signedness. Probably other compilers do too, at least if you enable warnings.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
