How does one guard against using an invalidated iterator?  If following an
.erase(), any invalidated iterators were set to .end() then you could test
for it, but they're not.

Any thoughts?

On a related note, I notice with VC++, incrementing an iterator past .end()
puts it back at .begin().  Is this behavior defined by the standard, or is
it compiler dependant?

Thanks!

- Tim
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tim Dyes wrote:

> How does one guard against using an invalidated iterator?  If following an
> .erase(), any invalidated iterators were set to .end() then you could test
> for it, but they're not.

Two things to do:

- prove all your code:
  which iterators are valid, one-past-the-end, dereferencable ?
  proofread it again

- test it with an appropriate debugging tool; the only tools I know
  of are SafeSTL, which is old (and has some bugs), and STLport, with
  the appropriate options (#define)

> On a related note, I notice with VC++, incrementing an iterator past .end()
> puts it back at .begin().

Well, it perhaps works with the std::list in VC++, but certainly
not with other containners ! The fact that it works is actually
an accident.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tim Dyes wrote:
>
> How does one guard against using an invalidated iterator?  If following an
> .erase(), any invalidated iterators were set to .end() then you could test
> for it, but they're not.
>
> Any thoughts?

Mark Twain said that the way to make money in the stock market is to buy
a stock and when it goes up, sell it. If it doesn't go up, don't buy it.
The same sort of thing applies to iterators: don't try to figure out
after the fact whether they're still valid. If you don't keep them
hanging around they won't become invalid. Use begin() and end() when you
need to create iterators into a container. Pass the result to a
function. If you're creating an iterator as a local variable you've
almost certainly not given enough thought to your design.

>
> On a related note, I notice with VC++, incrementing an iterator past .end()
> puts it back at .begin().  Is this behavior defined by the standard, or is
> it compiler dependant?

Well, maybe with some iterators, but not with all. And even then, it's
not guaranteed, and not something you should rely on. Incrementing an
iterator past end results in undefined behavior.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tim Dyes <tim.dyes@cobe.com> wrote:
: How does one guard against using an invalidated iterator?  If following an
: .erase(), any invalidated iterators were set to .end() then you could test
: for it, but they're not.

Boris Fomitchev's STL adaptation comes with the debug mode which
will warn you if you are trying to use a possibly invalidated
iterator. I don't know of any static checkers.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]