Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Georg Bauhaus <bauhaus@xxxxxxxxxxxxx>
- Date: Thu, 07 Jul 2005 15:54:57 +0200
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.
.
- Follow-Ups:
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Dmitriy Anisimkov
- Re: GCC 4.0 Ada.Containers Cursor danger.
- References:
- GCC 4.0 Ada.Containers Cursor danger.
- From: Dmitriy Anisimkov
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Matthew Heaney
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Dmitriy Anisimkov
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Martin Dowie
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Pascal Obry
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Dmitriy Anisimkov
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Pascal Obry
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Dmitriy Anisimkov
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Pascal Obry
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Dmitriy Anisimkov
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Georg Bauhaus
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Dmitriy Anisimkov
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Georg Bauhaus
- Re: GCC 4.0 Ada.Containers Cursor danger.
- From: Dmitriy Anisimkov
- GCC 4.0 Ada.Containers Cursor danger.
- Prev by Date: Re: GCC 4.0 Ada.Containers Cursor danger.
- Next by Date: Unchecked_Conversion and task pointer.
- Previous by thread: Re: GCC 4.0 Ada.Containers Cursor danger.
- Next by thread: Re: GCC 4.0 Ada.Containers Cursor danger.
- Index(es):
Relevant Pages
|