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: 238756252 Distribution: world References: <5k5hif$7r5@bcrkh13.bnr.ca> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada Date: 1997-04-30T00:00:00+00:00 List-Id: In article <5k5hif$7r5@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes: > I've looked at the ISO standard and the relevant FAQ's and tutorials, but I > still need some discussion or clarification about the management of objects > obtained via ``new'', because what I have read so far seemed rather vague in > one respect. > > Whose responsibility is it to destroy these objects? The Ada 95 standard > says that an implementation is permitted to implement garbage collection, > but not required to do so. Right. So, in actual fact it is implementation dependent. If the implementation provides GC, then you can forget about it. If not, you have to do something about it yourself. The most typical thing is to use manual deallocation via "Unchecked_Deallocation". At the moment, I know of only two cases where GC is provided: Intermetrics and Aonix Ada->Java compilers (each of which avail themselves of the Java VM GC). I'm working on a set of GC subsystems providing a range of generic GC variants which will allow you to create various collectors (various versions of mark-sweep, mark-compact, copying, generational, concurrent, treadmill, etc.) for your supplied type(s). This has its ups and downs wrt implementation provided GC and bolt on conservative collectors. The biggest down is a certain lack of transparency for the user - though you can in fact get pretty close to a natural style, maintain safety, be very flexible about it, and supply high time efficiency (yes, I know this is hard to believe, and it took a lot of head scratching to get there). Space efficiency is not so good for the more general cases (typically 8 bytes of overhead - making these variants poor for things like CONS cells or some such). Special cases are needed for strings and CONS cells (as these are just too useful and ubiquitous to ignore). I can't say for sure when all this will be ready, but probably some time this summer. > I know that it is possible to instantiate a generic freeing function > for explicitly destroying objects. But why is there is this lack of > symmetry in the language? Basically, this asymmetry is there because the designers did not think they could "require" GC (at least at the level of the high expectation of it for things like Lisp, Eiffel, ST, etc.) because many of the target areas of use would not need (or even require _not_ having) GC. But, the designers (especially Ada83) really were GC adherents, so they compromised and suggested that GC would be a very good thing for implementations to provide, but had to leave the door open for impls. only supplying manual deallocation. > On the one hand, you have a slick ``new''-expression to create > objects, but the complementary deletion operation is totally > obscured. Actually, it is not obscured enough! :-) I mean if you had GC you don't even _have_ such an operation in the programmers model. > Does this mean that explicit freeing of objects via an instance of > Unchecked_Deallocation is discouraged (due to the potential creation > of dangling references)? Oddly enough, this is indeed the implication. That's even why the thing is called "unchecked" (connoting something a bit dodgy). > Is it the reponsibility of the language implementation to > automagically detect when an object is no longer reachable and do > the appropriate deallocation, even if garbage is not collected? Not in any formal sense - i.e., there is nothing in the RM that suggests that an implementation really should have GC or its just a lame implementation. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com