A warning - comparison between signed and unsigned integer expressions

Question

I am currently working through Accelerated C   and have come across an issue in exercise 2-3   A quick overview of the program - the program basically takes a name  then displays a greeting within a frame of asterisks - i e  Hello   surrounded framed by   s    The exercise - In the example program  the authors use const int to determine the padding  blank spaces  between the greeting and the asterisks  They then ask the reader  as part of the exercise  to ask the user for input as to how big they want the padding to be   All this seems easy enough  I go ahead ask the user for two integers  int  and store them and change the program to use these integers  removing the ones used by the author  when compiling though I get the following warning      Exercise2-3 cpp 46  warning  comparison between signed and unsigned integer expressions   After some research it appears to be because the code attempts to compare one of the above integers  int  to a string  size type  which is fine  But I was wondering - does this mean I should change one of the integers to  unsigned int  Is it important to explicitly state whether my integers are signed or unsigned     cout  lt  lt   Please enter the size of the frame between top and bottom you would like     int padtopbottom   cin  gt  gt  padtopbottom    cout  lt  lt   Please enter size of the frame from each side you would like      unsigned int padsides    cin  gt  gt  padsides    string  size type c   0     definition of c in the program  if  r    padtopbottom   1  amp  amp  c    padsides   1       where the error occurs   Above are the relevant bits of code  the c is of type string  size type because we do not know how long the greeting might be - but why do I get this problem now  when the author s code didn t get the problem when using const int  In addition - to anyone who may have completed Accelerated C   - will this be explained later in the book   I am on Linux Mint using g   via Geany  if that helps or makes a difference  as I read that it could when determining what string  size type is

User · Answer

At the extreme ranges  an unsigned int can become larger than an int  Therefore  the compiler generates a warning  If you are sure that this is not a problem  feel free to cast the types to the same type so the warning disappears  use C   cast so that they are easy to spot    Alternatively  make the variables the same type to stop the compiler from complaining  I mean  is it possible to have a negative padding  If so then keep it as an int  Otherwise you should probably use unsigned int and let the stream catch the situations where the user types in a negative number

User · Answer

The important difference between signed and unsigned ints is the interpretation of the last bit  The last bit in signed types represent the sign of the number  meaning  e g   0001 is 1    signed and unsigned 1001 is -1 signed and 9 unsigned   I avoided the whole complement issue for clarity of explanation  This is not exactly how ints are represented in memory    You can imagine that it makes a difference to know if you compare with -1 or with  9  In many cases  programmers are just too lazy to declare counting ints as unsigned  bloating the for loop head f i   It is usually not an issue because with ints you have to count to 2 31 until your sign bit bites you  That s why it is only a warning  Because we are too lazy to write  unsigned  instead of  int

User · Answer

or use this header library and write       notEqaul less lessEqual greater greaterEqual if sweet  equal valueA valueB     and don t care about signed unsigned or different sizes

User · Answer

I had the exact same problem yesterday working through problem 2-3 in Accelerated C    The key is to change all variables you will be comparing  using Boolean operators  to compatible types  In this case  that means string  size type  or unsigned int  but since this example is using the former  I will just stick with that even though the two are technically compatible     Notice that in their original code they did exactly this for the c counter  page 30 in Section 2 5 of the book   as you rightly pointed out   What makes this example more complicated is that the different padding variables  padsides and padtopbottom   as well as all counters  must also be changed to string  size type    Getting to your example  the code that you posted would end up looking like this   cout  lt  lt   Please enter the size of the frame between top and bottom   string  size type padtopbottom  cin  gt  gt  padtopbottom   cout  lt  lt   Please enter size of the frame from each side you would like     string  size type padsides   cin  gt  gt  padsides   string  size type c   0     definition of c in the program  if  r    padtopbottom   1  amp  amp  c    padsides   1       where the error no longer occurs   Notice that in the previous conditional  you would get the error if you didn t initialize variable r as a string  size type in the for loop  So you need to initialize the for loop using something like       for  string  size type r 0  r  rows    r      If r and rows are string  size type  no error    So  basically  once you introduce a string  size type variable into the mix  any time you want to perform a boolean operation on that item  all operands must have a compatible type for it to compile without warnings

User · Answer

The primary issue is that underlying hardware  the CPU  only has instructions to compare two signed values or compare two unsigned values   If you pass the unsigned comparison instruction a signed  negative value  it will treat it as a large positive number   So  -1  the bit pattern with all bits on  twos complement   becomes the maximum unsigned value for the same number of bits     8-bits   -1 signed is the same bits as 255 unsigned 16-bits  -1 signed is the same bits as 65535 unsigned etc   So  if you have the following code   int fd  fd   open           int cnt  SomeType buf   cnt   read  fd   amp buf  sizeof buf      if  cnt  lt  sizeof buf          perror  read error        you will find that if the read 2  call fails due to the file descriptor becoming invalid  or some other error   that cnt will be set to -1   When comparing to sizeof buf   an unsigned value  the if   statement will be false because 0xffffffff is not less than sizeof   some  reasonable  not concocted to be max size  data structure   Thus  you have to write the above if  to remove the signed unsigned warning as   if  cnt  lt  0     size t cnt  lt  sizeof buf          perror  read error        This just speaks loudly to the problems   1   Introduction of size t and other datatypes was crafted to mostly work       not engineered  with language changes  to be explicitly robust and      fool proof  2   Overall  C C   data types should just be signed  as Java correctly     implemented    If you have values so large that you can t find a signed value type that works  you are using too small of a processor or too large of a magnitude of values in your language of choice  If  like with money  every digit counts  there are systems to use in most languages which provide you infinite digits of precision   C C   just doesn t do this well  and you have to be very explicit about everything around types as mentioned in many of the other answers here

User · Answer

It is usually a good idea to declare variables as unsigned or size t if they will be compared to sizes  to avoid this issue   Whenever possible  use the exact type you will be comparing against  for example  use std  string  size type when comparing with a std  string s length    Compilers give warnings about comparing signed and unsigned types because the ranges of signed and unsigned ints are different  and when they are compared to one another  the results can be surprising   If you have to make such a comparison  you should explicitly convert one of the values to a type compatible with the other  perhaps after checking to ensure that the conversion is valid   For example   unsigned u   GetSomeUnsignedValue    int i   GetSomeSignedValue     if  i  gt   0           i is nonnegative  so it is safe to cast to unsigned value     if   unsigned i  gt   u          iIsGreaterThanOrEqualToU        else         iIsLessThanU      else       iIsNegative

[c++] A warning - comparison between signed and unsigned integer expressions

Examples related to c++

Examples related to unsigned-integer