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,b307bd75c8071241 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: newbie Q: storage management Date: 1997/04/30 Message-ID: #1/1 X-Deja-AN: 238753944 Distribution: world References: <5k5hif$7r5@bcrkh13.bnr.ca> <33673929.F5D@space-elec.dofn.de> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada Date: 1997-04-30T00:00:00+00:00 List-Id: In article <33673929.F5D@space-elec.dofn.de> Marinus van der Lugt writes: > Kaz Kylheku wrote: > > > Whose responsibility is it to destroy these objects? The Ada 95 standard > > It is the programmers resposibility. Not necessarily. The RM certainly suggests that impls. with GC would be nice to have. Manual stuff is actually the thing "denegrated". > Garbage collection is the process that concatenates already > deallocated area's into one big area so memory does not get > fragmented. No, GC is what automatically determines dead stuff and once again makes it available for use. This may or may not compact or coalesce this space. > > this mean that explicit freeing of objects via an instance of > > Unchecked_Deallocation is discouraged (due to the potential creation of > > No. I don't know why it is called 'unchecked'_deallocation, but maybe it Actually, I think Kaz is spot on with this. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com