unsigned int vs int bitmasking.
Author
I wrote a program that did extensive use of bitmasking an int.
I then decided to change this bitmask to an unsigned int.
What could be some side-effects of interchanging this?
I use up to 24 bits in this integer, so I don''t see any possible bugs coming out of this.
thanks
Shouldn''t be any side effects. The only difference between a signed integer and an unsigned integer is how it''s interpreted by the CPU. If all you''re doing is bitmasking, shouldn''t be a problem.
Yeah, I don't think there could be any problem with that. It's the same amount of bits. The only difference is probably when you try to print out the actual value of that int, but when bitmasking, who cares what the actual value is?
[edited by - alnite on April 22, 2004 7:21:45 PM]
[edited by - alnite on April 22, 2004 7:21:45 PM]
Author
true....same number of bits, nobody cares.
that''s what i thought.
but i tend to overcomplicate things.
thanks
that''s what i thought.
but i tend to overcomplicate things.
thanks
The only way it will cause problems is if you are doing bitwise operations on a negative number. Even then it may be doing what you want it to do, but you had better know how the two's compliment notation works and be sure that you are getting the desired result. I generally use unsigned int unless I have a need for a signed int. If you are doing bitwise operations, it is generally a good idea to use unsigned values (not a huge deal as long as you understand what you're doing). Another possible reason to use unsigned instead of signed is that if you use a variable as an index into an array, and the index variable is a signed variable that has less bits than the machine, you will have to sign-extend the variable. In other words, on a 32-bit machine, if you use a signed 16-bit value as an array index, it will be slower than using any unsigned value as the array index. Of course, then you have to be careful you don't cause a bug doing something like this:
Since n is unsigned, you just created an infinite loop.
[edited by - Russell on April 22, 2004 9:32:07 PM]
for (unsigned int n = 10; n >= 0; n--) DoSomething(array[n]); Since n is unsigned, you just created an infinite loop.
[edited by - Russell on April 22, 2004 9:32:07 PM]
quote:Original post by Russell
The only way it will cause problems is if you are doing bitwise operations on a negative number. Even then it may be doing what you want it to do, but you had better know how the two''s compliment notation works and be sure that you are getting the desired result. I generally use unsigned int unless I have a need for a signed int. If you are doing bitwise operations, it is generally a good idea to use unsigned values (not a huge deal as long as you understand what you''re doing). Another possible reason to use unsigned instead of signed is that if you use a variable as an index into an array, and the index variable is a signed variable that has less bits than the machine, you will have to sign-extend the variable. In other words, on a 32-bit machine, if you use a signed 16-bit value as an array index, it will be slower than using any unsigned value as the array index. Of course, then you have to be careful you don''t cause a bug doing something like this:for (unsigned int n = 10; n >= 0; n--) DoSomething(array[n]);
Since n is unsigned, you just created an infinite loop.
[edited by - Russell on April 22, 2004 9:32:07 PM]
i''ve must have missed that in programming class!!
how is that gonna cause an infinite loop??
.....nevermind i see it now. since n is unsigned it can only go to zero and no lower.
There is a big difference. The result of a right shift on a signed value depends on the compiler. For example, the value of y in this code could be either ffffffff or 7fffffff.
Quoting the Microsoft Visual C++ docs:
Microsoft Specific
The result of a right shift of a signed negative quantity is implementation dependent. Although Microsoft C++ propagates the most-significant bit to fill vacated bit positions, there is no guarantee that other implementations will do likewise.
END Microsoft Specific
int x = 0xffffffff;int y = x >> 1; // y may be 0xffffffff or 0x7fffffff Quoting the Microsoft Visual C++ docs:
Microsoft Specific
The result of a right shift of a signed negative quantity is implementation dependent. Although Microsoft C++ propagates the most-significant bit to fill vacated bit positions, there is no guarantee that other implementations will do likewise.
END Microsoft Specific
Right shifting is the big one. Typically implementations do an arithmetic shift right rather than a plain shift right when the data being shifted is signed. Arithmetic shift right basically exists so you can use >> to divide negative numbers by a power of 2. If you''re working with bits at all, most of the time you''ll want to use unsigned int or at least cast carefully to unsigned int. For instance... if you''re packing color components into an RGB565 short. Anything that involves a right shift.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
