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!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Visibility of Indexing aspects Date: Mon, 6 Aug 2018 16:46:14 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Mon, 6 Aug 2018 21:46:15 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="6064"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:54068 Date: 2018-08-06T16:46:14-05:00 List-Id: "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. Randy.