Re: GCC 4.0 Ada.Containers Cursor danger.

[Georg Bauhaus <bauhaus@futureapps.de>]

Dmitriy Anisimkov wrote:


> Depend on what to do with returned cursor later.

Precisely.

> In some cases

And why should we base decisions about the design of a standard
library on "In some cases..."?


> <<I'm assuming you somehow found a way around the case where you have
> to compare strings and/or hash them in order to repeatedly
> find a key? Or how do you remember a position in a dynamic container?>>
> 
> 
> Algorithm should be designed for be able to get value by key just once.
> Use and modify it and put it back.

Are you suggesting that all library algorithms can be designed so
that each value in a container is used no more than one time only?

> <<And how do you _not_ loose efficiency if on every loop
> iteration you check the validity of your variables related
> to container elements? >>
> 
> Iteration could be done in the generic routine too. 

You don't address the problem of checking access, as being behind a
generic iteration or using cursors in your programs has nothing
to do with checking or not. Checking takes time.
Therefore, if iteration is checking every access, iteration will
have to run more slowly, unless you have found some miraculous
speedup device called "zero cost access check". Have you found one?

Did you have a look at

  Iterate(C, P'access);


> Like in
> Generic_Iteration but with a one more out parameter "Quit : out
> Boolean" in Process procedure generic parameter.

Again, this doesn't say anything about checking multiple
Cursors pointing to the same element.


> << If there were a number of generic algorithms working on
> top of Ada.Containers, would they be useful in your work?
> 
> How about idiomatic uses of the library? >>

Again, will idiomatic use of library algorithms help?
Will generic algorithms help? (Notice that generic algorithms here are
not generic subprograms in the container packages. They are algorithms
of general use that can be used with many containers.)


> Some of the elements linked directly by Access type.
> 
> The operations on them is get by key, modify by key, iteration untill
> condition, and all of them is without cursors and without find more
> then once.
> 

And? If you have "some elements linked directly by access type"
that sounds like a linked list to me. I guess you do "iteration
until" by pointers, and prepare for null access exceptions for
unexpected cases.
If this is the way and the truth and the light for a general
library...


Consider an iteration-until approach with a linked list in
the following situation:

- you get m stock exchange records per second
- you have to filter out some of them
- the filter changes every <insert time interval here>

The filter is: belongs_to_this_set_of_certificates(...)
where the set isn't tiny. It is also changing with time,
as I said.

We use a Set and Find to see whether a record is in the set.
(C++ STL, by availability)

Should we be looking upt certificates by building our own linked
list and use it as a set?
And therefore have every lookup run in T(n/2) where n is the size of
the linked-list-set?
You can't do this linear search when time matters, i.e. when
you build a real time system.



-- 
----------------------------------------------------------------
Georg Bauhaus                              bauhaus@futureapps.de
Future Apps GmbH                        http://www.futureapps.de
phone: +49 203 306 1560