STL compiler warning, very strange

[Bill Jurasz]

Martin v. Loewis wrote:
> 
> > I am getting a rather strange warning (using -Wall) from gcc with
> > STL with the following code.  When using an iterator in deque::erase()
> > I'm getting a warning about comparing a signed to an unsigned:
> [...]
> >         schedule_q.erase( index);  <-- here
> [...]
> > /usr/local/include/g++/stl_deque.h: In method `struct
> > __deque_iterator<instruction_t,instruction_t &,instruction_t *,0>
> > deque<instruction_t,__default_alloc_template<false,0>,0>::erase<
> > instruction_t, alloc, 0>(struct __deque_iterator<instruction_t,instruction_t
> > &,instruction_t *,0>)':
> > SEQ_FPU_Irr.C:369:   instantiated from here
> > /usr/local/include/g++/stl_deque.h:533: warning: comparison between signed and
> > unsigned
> 
> Thanks for your bug report. Please have a look at the error again, it
> indicates that the problem is in line 533 of stl_deque.h, i.e. in
> libstdc++ proper. It shouldn't be too difficult to correct this in
> your installation of gcc; please send a patch to
> gcc-patches@gcc.gnu.org when you found a fix that
> works.

Ok.  Here I believe is the problem:



  iterator erase(iterator pos) {
    iterator next = pos;
    ++next;
    difference_type index = pos - start;
    if (index < (size() >> 1)) {            <-- line 533
      copy_backward(start, pos, next);
      pop_front();
    }
    else {
      copy(next, finish, pos);
      pop_back();
    }
    return start + index;
  }



Size is returned as an unsigned int, which makes sense, as negative
sizes are hard to imagine.  The difference_type is a ptrdiff_t,
which is signed.  This is so that if you subtract pointers you can
get a negative number.  I can understand this.  However, in some
cases, such as this one, you can verify that the pointer difference
will always be positive.  A cast of index to unsigned should work
for all cases.  It is also why the compiler is complaining about
comparing signed and unsigned numbers.

This is cumbersome, as this will crop up in many, many places in
STL.  And not all cases will guarantee a difference will be positive.

I'm wondering if there is a better solution than me hacking up our
version in the few places I've managed to find this problem thus far.
Where we work, we strive to remove all compiler warnings from our
code.  But it is frustrating when STL, standard libraries and such
are not so clean.

Alternately, why bother issuing a warning if you are comparing
signed and unsigned numbers in the first place?  What is the harm
exactly?  As an example, notice that the following do not issue
any warning at all:

   unsigned x;

   if (x < 0)   // can never be true
   if (x >= 0)  // will always be true

Seems silly to issue warnings in some cases but not the above.
Worse, it may get optimized out with no warning at all.

-- 
Bill Jurasz 

Lottery: A tax on people who are bad at math.
begin:          vcard
fn:             Bill Jurasz
n:              Jurasz;Bill
org:            Somerset, SPS-ASP<BR><img src= http://www.mot.com/img/motobtn.gif ><IMG SRC=" http://www.mot.com/img/homeDNA.gif ">
adr:            7700 W Parmer Lane;;;Austin;TX;78729;USA
email;internet: bjurasz@ibmoto.com
title:          Verification Engineer
tel;work:       512-996-6095
tel;fax:        512-996-
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard