Re: bug in library standard 23.2.1.3/4

[Steve LoBasso <slobasso at yahoo dot com>]

> On 15/02/07, Steve LoBasso <slobasso@yahoo.com> wrote:
> > The standard states in 23.2.1.3/4:
> >
> > Effects: ... An erase at either end of the deque invalidates only the iterators and the references to the erased elements.
> >
> > This does not state that a previously copied value of end() will be invalidated, but it must be invalidated.
> > Also, if a change to the standard is made, it should also consider the invalidation requirements of end() in the context of a container with only a single element when that element is erased.
> >
> > I have enclosed a code sample showing the problem.

> I don't see a problem with this code. As you say, z has become
> invalidated. However, according to the standard, acting on invalidated
> iterators is undefined. The compiler isn't required to "clean up"
> invalidated iterators, and in general doing so would be very
> expensive.

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].

So there are two issues here.
1. The standard needs to be re-worded to account for end() invalidation. This is why I titled this as a bug in the standard.
2. And the debug implementation needs to be adjusted to invalidate end() iterators during some operations.

>
> > Also the debug deque container implementation doesn't handle this situation very gracefully.
>
> This could be fixed. What do you mean "not gracefully"?

When I say gracefully, I mean reported as an invalid iterator use by the debug implementation.

   -Steve





 
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/