Re: GCC 4.0 Ada.Containers Cursor danger.

[Georg Bauhaus <bauhaus@futureapps.de>]

Maxim Reznik wrote:

> I look in all my Ada programs. There are a few loops per container,
> no more that 2 or 3 at once. Because cursors's main purpose is
> iteration over containers I think there will be a few cursors per
> container usually.

Are these inner loops or outer loops? How often are
they run?


> For instance, Remove will iterate over all cursors for
> the container, check target of cursor and set cursor to
> No_Element if target match removed element.

> The method I propose costs O(cursors per container) performance
> penalty. I think it's acceptable cost for safety.

Could you indicate which cost you have in mind,
and in which cases it is acceptable? E.g. explaining in T(n) etc terms
your Remove analysis above?


> In rare cases when user encounter performace limits he
> could easy implement his own container,

Just repeating the word "easily" doesn't convince me that programming
NIH containers is an easy task. I find it puzzling that people
keep talking safe, safe, safe, and then roll their own
containers, thinking this is easy and safe.

OTOH, Matthew demonstrates how you can add checking on top
of Ada.Containers when you have reason not to trust your Cursors.


> with limited functionality.
> And he will know exactly where dangling references cound apear.
> 
> Now cursor is like grenade. You don't know what happens if you
> use it. Because you can't check is it valid cursor.

We don't know what happens if we blindly use a pointer,
too. They could have been deallocated without check,
for a reason. Cursors aren't fully checked pointers, true. But
there is a reason that Unchecked_Deallocation is in the
Ada language. You could ban Unchecked_Deallocation for
the same reasons you give for banning Cursors.