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,3498dd887729ed19 X-Google-Attributes: gid103376,public From: lars.farm@ite.mh.se (Lars Farm) Subject: Re: Garbage Collection in Ada Date: 1996/10/15 Message-ID: <19961015122319668722@dialup98-6-12.swipnet.se>#1/1 X-Deja-AN: 189528345 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> <199610132138291604607@dialup101-6-14.swipnet.se> organization: pv nntp-posting-user: s-49817 newsgroups: comp.lang.ada Date: 1996-10-15T00:00:00+00:00 List-Id: John Howard wrote: > GC just provides *automatic* deallocation of "unreachable" dynamically > allocated objects. GC is not cost-free. Ada 95 flexibly provides a > programmer with capable mechanisms to manually manage memory. Plus the > safeguards of Ada help minimize creating slop to clean up and so the > deallocation can likely be managed easily enough manually. With GC the problem of "clean up" of memory is defined away. There is no way to be "sloppy" about deallocating memory with GC. There is no problem, pure and simple. That this is hard to accept is IMHO a clear indication that this really is a hard problem (without GC). We are so afraid of memory leaks that we find it very hard to accept an automatic solution. Note: this doesn't mean that GC solves every conceivable memory related problem, but knowing when to release memory is solved so the result is not "slop to clean up". > But certain highly tuned programs may require special > storage-management schemes tailored to the application. > Section 19.5.1 will describe advanced mechanisms for specifying > programmer-defined subprograms to be invoked by the evaluation of > an allocator or a call on an instance of Ada.Unchecked_Deallocation. Sure, if a solution solves a majority of problems and leaves some to traditional techniques, is that not better than a solution that solves none? -- Lars Farm, lars.farm@ite.mh.se