Re: GCC 4.0 Ada.Containers Cursor danger.

[Matthew Heaney <matthewjheaney@earthlink.net>]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> Dmitriy Anisimkov wrote:
> >    M.Delete (C2);
> >    pragma Assert (not Has_Element (C2));
> >    pragma Assert (not M.Contains ("two"));
> > --  double hash overhead.
> >    Replace_Element (C, -2);  -- dangling cursor
> 
> I thought the Replace_Element line was the source of an
> undetected dangling cursor in your initial example.

Yes, that's my understanding too.


> Supposedly the new checking is inside Replace_Element, which now fails
> with "bad cursor in Replace_Element".

Some of that checking was already in place for the hashed map.  Did the
OP compile with assertions enabled?

What I find baffling is that the OP complained that the cursors were
dangerous, since the library failed to detect a dangling cursor
reference.  But when the dangling reference *is* detected, the OP
complains that the library still isn't good enough, either because
cursors have "too much overhead," or aren't "safe enough."  (If the
library can detect dangling cursors, then what other safety issues are
there?)  

His main complaint seems to be that cursors exist at all.  Yes, cursors
are tied to the iteration mechanism (a compromise of sorts, since the
language itself doesn't have support for "real" iterators), but cursors
have uses beyond mere iteration.


> The two asserts above look like "informative" assertions
> to me, expressing what Delete has done. 

Yes, exactly.


> They are not in the library, they are in a client program, and
> therefore don't add overhead to library subprograms at all. They also
> don't check C.

Note that if I had checked cursor C (by calling Has_Element, say), then
that would have just raised the assertion error sooner.