Re: GCC 4.0 Ada.Containers Cursor danger.

[Matthew Heaney <matthewjheaney@earthlink.net>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> At this point, Containers implementations are immature, so it's really
> incorrect to draw any conclusions from them. And, Matt seems to have a
> strong aversion to checks of any kind. Every check that we mandated in the
> containers library was over his objections. So I don't find it surprising
> that his implementation of the containers doesn't include much checking.

I had originally included checks that didn't require any extra storage
overhead, controlled by the use of pragma Assert.  However, it turns out
that even if you compile with assertion checks on, whether assertions
are enabled is decided at the time of compilation of the generic.  And
in the GNAT runtime, all checks (including constraint checks -- gulp!
I'm still fixing that...) are turned off.  I wanted additional checks to
be controlled by the user (at the point of instantiation), but I still
haven't figured out how to do that.

To make things absolutely bullet-proof, I think you'd need at least a
per-element reference count.  (That, or have the container maintain a
list of extant cursors, which you would then have to search.)  If you
attempt to delete a node for which the ref count is greater than 0, then
you could raise an exception.  (This might actually produce a false
positive, since the real error is attempting to dereference the cursor,
not merely delete the node to which it is bound.  But to solve that,
you'd have to move the node onto a free list, and during the dereference
check to see whether the node is on the free list or not.)

So yes, there are some extra checks that can be performed, but I still
prefer to let the user control whether they're enabled.

You are also correct about immaturity of implementations.  I'm still
developing a set of unit tests for the containers.  (In fact, I found a
bug this morning in the Merge operation of the list container.)  So
there's still lots of work to do, especially with the post-York API
coming down the pipe...

-Matt