This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: bug in library standard 23.2.1.3/4
- From: Steve LoBasso <slobasso at yahoo dot com>
- To: AlisdairM <alisdair dot meredith at uk dot renaultf1 dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Thu, 15 Feb 2007 15:12:44 -0800 (PST)
- Subject: Re: bug in library standard 23.2.1.3/4
> 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.
I'm no standards expert, but I do believe that when they say ONLY they mean only.
I believe that very little is said because, of all the containers, only deque and vector can invalidate end() during an erase() operation. vector's situation is simpler and the wording happens to be correct. deque is more ambiguous. This is either a bug in the standard or a bug in [probably] every implementation of deque out there. I happen to believe that it is a bug in the standard.
BTW vector 23.2.4.4/3 states:
erase(...)
effects: invalidates iterators and references at or after the point of the erase.
This would include end() as it is defined.
> An implementation is usually free to invalidate an end iterator as it
> feels, including never if it so chooses.
I would be very surprised if this is true.
-Steve
____________________________________________________________________________________
Need a quick answer? Get one in minutes from people who know.
Ask your question on www.Answers.yahoo.com