From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Map iteration and modification Date: Mon, 1 Jan 2024 21:55:12 +0100 Organization: A noiseless patient Spider Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 1 Jan 2024 20:55:12 -0000 (UTC) Injection-Info: dont-email.me; posting-host="910c87df5db3b8fa556d1a1abd71f156"; logging-data="2462487"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18uzGVvyEdCF0Fy07+VbNhORvhjrQU9tms=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:3PyFHBS4Dzxw7f3WqQtoKabFC/Q= Content-Language: en-US In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:65950 List-Id: On 2024-01-01 20:27, G.B. wrote: > On 29.12.23 17:52, Dmitry A. Kazakov wrote: > >>> Suppose that there is a way of orderly proceeding from one item to >>> the next. >>> It is probably known to the implementation of map. Do single steps >>> guarantee transitivity, though, so that an algorithm can assume the >>> order to be invariable? >> >> An insane implementation can expose random orders each time. > > An implementation order should then not be exposed, right? IMO, an order should be exposed. Not necessarily the "implementation order" whatever that might mean. > What portable benefits would there be when another interface > is added to that of map, i.e., to Ada containers for general use? It is same benefit Ada arrays have over C's T* pointers and arithmetic of. Cursor is merely a fat pointer. > Would it not be possible to get these benefits using a different > approach? I think the use case is clearly stated: > > First, find Cursors in map =: C*. > Right after that, Delete from map all nodes referred to by C*. Right. Find cursors, store cursors in another container, iterate that container deleting elements of the first. Now, consider that the cursors in the second container become invalid (dangling pointers). If you wanted to delete them immediately from the second container, you would return the square one! (:-)) With a positional access interface it would be just (pure Ada 95): for Index in reverse 1..Number_Of_Elements (Container) loop if Want_To_Delete (Get (Container (Index))) then Delete (Container, Index); end if; end loop; > For deleting, this thread has shown a loop that calls Delete > multiple times right after collecting the cursors. > And it is boilerplate text.  Could Maps be improved for this use case? See above. > [Bulk deletion] We do get bulk insertion in containers.  Also, > A.18.2 already has bulk Delete operations.  Similarly, > the Strings packages have them. > > [No thread safety needed] If standard Ada maps are usually operated > by just one task, stability of Cursors is predictable. > > Then, with or without automatic management of storage, > when My_Map is from an instance of Ordered_Map, > >    Start  := In_13th_Floor (My_Map.Ceiling (13.0)); >    Finish := In_13th_Floor (My_Map.Floor (Fxd'Pred (14.0))); >    My_Map.Delete ( >       From    => Start, >       Through => Finish); The case is more general: delete pairs satisfying certain criterion. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de