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: Prologue and epilogue aspects Date: Wed, 31 Jan 2018 18:17:17 -0600 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Thu, 1 Feb 2018 00:17:18 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="25481"; 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; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:50233 Date: 2018-01-31T18:17:17-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:p4sm09$126n$1@gioia.aioe.org... > On 30/01/2018 23:02, Randy Brukardt wrote: ... >> Huh? If there is no implicit finalization, then there is no need for >> controlled types at all, as they serve no purpose. (If you want to >> explicitly finalize things, you can define any subprogram for that >> purpose. > > "Implicit" meant called upon implicit destruction, e.g. when access types > go out of the scope. That thing is not needed. I don't see other reason > for the Controlled_Interface to induce hidden components. (1) Subpools and mutable types also need lists of some sort to properly do finalization. (2) The reason for the "out of scope" rules is so that Finalization can be used for resource allocation beyond simply memory management. For instance, to return device (handles) to the OS when they won't be used any more. We felt that there shouldn't be any leaks in that. (3) I think you would have to ban nested access types (that can go out of scope before program end) that designate type with parts of this kind of controlled type, lest the allocation of such objects lead to guarenteed storage leaks (one doesn't want to use Unchecked_Deallocation if they don't have to). (4) Chains for all controlled objects work best with exception handling, as it isn't necessary to enter every scope to try to clean up objects, and in particular, one doesn't have to deal with the horror of partially initialized objects (whose initialization was interrupted by an exception). To use your static implementation, you also have to use a static implementation of exceptions, and somehow keep track of initialization of objects (and every part of such objects) in each scope. It's possible (since AdaCore has managed it), but it's fiendishly complex and definitely beyond what I can do. Adopting rules that only AdaCore has enough smarts to implement would likely ensure that there never will be any other competing implementation. I think that's bad policy; even if no other implementation appears, closing the door seems like the wrong way to go. Randy.