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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Visibility of Indexing aspects Date: Tue, 7 Aug 2018 00:12:12 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: IzvqdhUtDGKIMCldyDtZ+w.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:54073 Date: 2018-08-07T00:12:12+02:00 List-Id: On 2018-08-06 23:46, Randy Brukardt wrote: > "Dan'l Miller" wrote in message > news:cc25c794-5986-4f6e-9d5e-0ec20a4f47d0@googlegroups.com... > ... >> Ummmmmmmmm, what is so incredibly "expensive" about Element => >> Self.Data(Index)'Access in OP? > > Nothing is expensive about *that*, but it's also very unsafe by itself (this > either prevents a container from ever reusuing memory, or essentially > requires being OK with dangling pointers and the erroneousness that they > cause). > > Our requirement was that the user-defined dereference mechanism needs to be > safe (at least possible to be safe), and that requires the container to be > able to find out when the dereference ceases to exist. At that point, the > container can free the underlying memory if need be. (For an extreme > example, consider a persistent container, where the object only should exist > in memory so long as it is being used there.) The design that we came up > with for Ada 2012 uses finalization for this notification; we looked at > other mechanisms, but they would have had similar overhead. > > The Ada containers use the finalization to clear the tampering check (which > prevents deleting of elements while the dereference exists); other uses are > possible, of course. > > Without these sorts of checks, Ada containers would be no more safe than C > code. In particular, Ada programmers do not expect checked indexing to be > unsafe, so syntax of C(I) being unsafe would be a particular surprise. Right, exposing references, e.g. having named types of and explicit objects of, is always either unsafe or both unsafe and inefficient. There is no satisfactory solution on that path. No way to decompose A(I):=X literally. After fixing Ada type system we should better try Update(A,I,X). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de