Experimental Physics and
Industrial Control System

Chris Larrieu <[email protected]> · Fri, 08 Dec 2000 09:09:09 -0500

Andrew,

  I now understand better what you intend.  But the sort of 
"undefined" behaviors I've encountered are fairly arcane problems 
arising from vaguaries in the standard.  For example, consider the 
following:

  list<t> my_list;
  list<t>::const_itertor it;       // read-only iterator

  it = my_list.begin();
  if (it != my_list.end()) cout << "groovy" << endl;

The comparison between an iterator and a const_iterator is not
defined by the standard.  The only portable solution is to
cast my_list.end() to a const iterator:

  if (it != (list<t>::const_iterator)my_list.end()) 
    cout << "groovy" << endl;

But, both g++ and MS VC++ quietly permit the first comparison, 
while the HP aCC compiler specifically disallows it, specifically 
because it's undefined.  You might take this in one of two ways: 
either as evidence that HP is behind the times, or that HP avoids 
supporting de facto standards.

If you're interested, here's some email I sent to the HP aCC mailing
list:

Howdy,

  After reviewing the comments posted on this list, and looking
over the ISO/IEC 14882 standard, I've come to the conclusion
that the best thing to do is to cast the iterator returned by
end() to a const_iterator.  Here's why:

  list<t>::end()           --> returns an iterator
  const list<t>::end()     --> returns a const_iterator

but, 

  list<t>::iterator        --> references a t
  list<t>::const_iterator  --> references a const t

  Now, the standard explicitly states that an iterator can
be explicitly converted to a const_iterator, so the following
is perfectly valid:

  class blah
  {
    list<t>  my_list;

    ...

    void f1 (void)
    {
      list<t>::const_itertor  it;       // read-only iterator

      it = my_list.begin();
      if (it != (list<t>::const_iterator)my_list.end())
        cout << "groovy" << endl;
    }
  };

  Given that the standard allows a conversion from iterator -->
const_iterator, you might think that the overloaded != operator
should perform the conversion implicitly.  The rules governing 
how the operands to such a method are selected allow a less-qualified 
type to be implicitly converted to a more qualified type.  Here,
however, the relationship between (class iterator --> class
const_iterator)
is not the same as the relationship between (class a --> const class a).

  So the problem is sort of this disconnect between what is happening
intuitively and what is happening technically.  Apparently testing
equality between iterator and const_iterator objects is a desired
feature for the next revision of the standard.  See:

  http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#179

  Best Regards,

Chris

-- 
Christopher A. Larrieu
Computer Scientist, Acc. Controls Group
Thomas Jefferson National Accelerator Facility

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System