From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Re: Map iteration and modification Date: Tue, 2 Jan 2024 17:40:06 +0100 Organization: A noiseless patient Spider Message-ID: References: Reply-To: nonlegitur@notmyhomepage.de MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 2 Jan 2024 16:40:06 -0000 (UTC) Injection-Info: dont-email.me; posting-host="95a70fd134f63a152e8b4dbf5dadc299"; logging-data="2918751"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+2Bjia2dvTw0gtCC5PC2kxAZlhIVWhJ/s=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:aA6xGZFh8+YPYs27EgJwOXNlWlM= In-Reply-To: Content-Language: en-US Xref: news.eternal-september.org comp.lang.ada:65951 List-Id: On 01.01.24 21:55, Dmitry A. Kazakov wrote: >> 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! (:-)) OK, yet if indicating nodes in a container is designed to survive any deletions, leaving nothing dangling i.e., doesn't this limit the way in which implementations can store nodes? Seems like every "pointer" (= (Container, Position)) needs to know its element, and/or the container will have to equip its storage management with a "vacuuming" algorithm accordingly. Transactions seem more flexible (a locking flag in a sequential algorithm?), a dedicated operation looks simpler than both.