Jump to content
  • Advertisement
Sign in to follow this  
I_Smell_Tuna

Signed and Unsigned

This topic is 4744 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
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

Share this post


Link to post
Share on other sites
All types are signed by default, except char which is up to the compiler. (I think)

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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
}

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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:

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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!