This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug in library standard 23.2.1.3/4


AlisdairM wrote:
Steve LoBasso wrote:

The problem is the standard doesn't say that end() will become
invalid. This is probably why the debug implementation doesn't catch
the problem [ie. compiling with -D_GLIBCXX_DEBUG].

<delurk>


If I understand correctly, the standard says very little about end
iterators, wrt invalidation.  THe weasel-wording is that most of the
wording describing when an iterator is invalidated talk about iterators
in the sequence, or similar, but end iterators are
one-past-the-end-of-the-sequence, but not actually in the sequence, and
so are not covered.

There are three kinds of iterators: dereferenceable, valid, and singular. A past-the-end iterator is a valid non-dereferenceable iterator into the sequence. (I couldn't find any text that says otherwise.)


An implementation is usually free to invalidate an end iterator as it feels, including never if it so chooses.

Since end() is a valid iterator into the container and the text clearly says that erasing at either end of a deque invalidates only iterators pointing to the erased elements, the requirement is that all other valid iterators must remain valid after the call. I'm not saying that's what we want or that it's even implementable, just how I read it.

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]