From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f2690a5e963b61b6 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.icl.net!proxad.net!proxad.net!newsfeed.arcor.de!news.arcor.de!not-for-mail Date: Wed, 06 Jul 2005 14:14:34 +0200 From: Georg Bauhaus Organization: VoCal web User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GCC 4.0 Ada.Containers Cursor danger. References: <1120474891.635131.216700@g44g2000cwa.googlegroups.com> <1120575076.876798.108220@g44g2000cwa.googlegroups.com> <1120583470.429264.325450@g43g2000cwa.googlegroups.com> <1120633337.871534.305480@g43g2000cwa.googlegroups.com> <42cb9003$0$22761$9b4e6d93@newsread2.arcor-online.net> <1120639058.526631.152480@g49g2000cwa.googlegroups.com> In-Reply-To: <1120639058.526631.152480@g49g2000cwa.googlegroups.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42cbcb1d$0$22781$9b4e6d93@newsread2.arcor-online.net> NNTP-Posting-Date: 06 Jul 2005 14:14:21 MEST NNTP-Posting-Host: d60613a9.newsread2.arcor-online.net X-Trace: DXC=7QAYfm17R4DUhhl_USDNiOQ5U85hF6f;DjW\KbG]kaMHU7^]5?JhlBNGUPSmN8fVU@UUng9_FXZ=C>:=P9Ihe`BH@Z?dZ]MOidE X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:11895 Date: 2005-07-06T14:14:21+02:00 List-Id: 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..."? > < 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? > < 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 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