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
- Replies:
- Re: C++ API backwards compatibility Andrew Johnson
- References:
- C++ API backwards compatibility Jeff Hill
- Re: C++ API backwards compatibility Andrew Johnson
- Re: C++ API backwards compatibility Chris Larrieu
- Re: C++ API backwards compatibility Andrew Johnson
- Navigate by Date:
- Prev:
Re: C++ API backwards compatibility Andrew Johnson
- Next:
Re: C++ API backwards compatibility Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
<2000>
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: C++ API backwards compatibility Andrew Johnson
- Next:
Re: C++ API backwards compatibility Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
<2000>
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|