Re: GCC 4.0 Ada.Containers Cursor danger.

[Georg Bauhaus <bauhaus@futureapps.de>]

Dmitriy Anisimkov wrote:

> If I need direct access to elements, I put dynamically allocated object
> (maybe smart pointer) into container, and keep access where i need.

But you can do that now with Ada containers.

> generic
>    procedure Process (Key : Key_Type; Value : Value_Type; Stop : out

If you are worried about Ada 2006's Iterate using Cursors internally
(in the Process procedure), what makes you sure that the programmers
writing the procedure for Process in Generic_Iterate above will
not use the wrong key in their procedure?

If the use the (logically) wrong key, there will be a bug that is even
harder to find than if a Cursor becomes invalid. This is because
you can't notice the error. No checks and not even detectable memory
corruption due to erroneous execution. So are keys really always
more safe than Cursors?

Second, we loose a few things of general use
if we can only use smart pointers or keys instead of standard Ada
cursors.
 For example, for any algorithm working on Cursors using their
operations and little else (generic algorithms a la STL) we will have to
reinvent and reconsider every cursor operation as a smart pointer
operation.


> I think it is more honestly than to keep cursors.

"maybe smart pointer"... 
What is a maybe-type? :-)


> So I take responsibility for deallocation. And library does not have to
> check
> for invalid cursors.

If you take the responsibility that's fine. But why do you expect
your programmers to produce improved code lacking Cursors,
when they will have to write their own deallocation instead?



> <<How can a linear search be as fast as
> direct access via a cursor?>>
> 
> Strange question. I do not know answer. I did not propose linear
> search.

When you mentioned the Internet Currency Trading system, you said,
"Some of the elements linked directly by Access type."
I had interpreted this to mean a linked list. I guess this interpretation
was wrong?


> It would be better to put elements into container
> after
> the loop.

Hmm... My point was to show a repeated update of elements
in a map; I had omitted later processing in each loop
iteration but anyway, to complete the picture:

  loop
    read input used for element replacement
    modify element values in the map (, graph, net, ...)
    foreach need loop
       recompute value based on elements in the container  -- omitted
       write output -- omitted
    end loop;
  end loop;

So there isn't necessarily a tasking issue.