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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,aa968038a51ee866 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Q: Ada.Unchecked_Deallocation Date: 1996/07/21 Message-ID: #1/1 X-Deja-AN: 170627370 references: <31E5D4D1.11DB36E1@jinx.sckans.edu> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-07-21T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >We talked at one point with Tuck about a pragma that would be applied to >a type something like > > Finalization_Is_Used_Only_For_Freeing_Storage (type); > >(well we need a better name :-) > >the effect would be to simply ignore finalize calls at the outer level, ... I believe an earlier version of Ada 9X proposed that. Or maybe an earlier version of the AARM suggested we *might* propose it. If you feel like digging through old versions, you might run across a better name than the above. ;-) It does sound like a useful feature. Note that you might want to do this for non-memory resources, too. E.g. you might know that your operating system will close any remaining open files. >... or, >in the case of a GC Ada 95, to ignore all finalize calls for the type. That part was never proposed, as far as I can remember. Finalization in the presence of GC is a bit tricky. It's not obvious how one should define the *order* in which various finalizations take place. Also, it's hard to implement if the Finalize routine is allowed to resurrect garbage -- that is, the GC determines that some object is garbage, runs its Finalize, and the Finalize plants a pointer to the object (or something accessible from the object) somewhere global. - Bob