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,5653f0bd43045b85 X-Google-Attributes: gid103376,public From: Keith Thompson Subject: Re: garbage collection Date: 1999/08/20 Message-ID: #1/1 X-Deja-AN: 515331688 Sender: kst@king.cts.com References: X-Trace: thoth.cts.com 935197470 21687 198.68.168.21 (21 Aug 1999 01:04:30 GMT) Organization: CTS Network Services Newsgroups: comp.lang.ada X-Complaints-To: newsmaster@cts.com Date: 1999-08-20T00:00:00+00:00 List-Id: tmoran@bix.com writes: > > > No. When the access type goes out of scope there is clearly no way > > > the storage can be on the target end of a pointer, so the > > > implementation should free that storage. > > > > Just to clarify, most implementations don't actually do this. > Why? Is an implementation not easy, efficient, and predictable? > And of course overidable by the user simply by raising the > level where the access type is declared. > It seems undesirable to have to specify a number, big enough, but > not too big, for the amount of storage needed when you merely want > to get automatic deallocation. I just realized that I had mis-read the article to which I was responding. What "most implementations don't actually do" is general garbage collection, i.e., freeing allocated memory after it becomes inaccessible. Freeing allocated memory when leaving the scope of an access type is much easier. I *think* that most implementations don't even do this, but I'm not as sure on this point. It does impose a little extra overhead, in both time and space. Specifying the 'Storage_Pool attribute is a very powerful and under-used feature, IMHO. The biggest obstacle to its use, I suspect, is the need to implement the Storage_Pool operations. If System.Storage_Pools also provided routines for dereferencing access values (perhaps one each for reading and writing), and perhaps also for initialization and finalization of access objects, it would be even more powerful. I haven't entirely thought this through, so it may be a bad idea for some reason. -- Keith Thompson (The_Other_Keith) kst@cts.com San Diego Supercomputer Center <*> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle.