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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c233446a6027f1ed X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-15 15:23:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!small.news.tele.dk!207.115.63.138!newscon04.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr13.news.prodigy.com.POSTED!3bae8248!not-for-mail From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: access / freeing memory References: X-Newsreader: Tom's custom newsreader Message-ID: <%WHY8.1173$tt5.52024504@newssvr13.news.prodigy.com> NNTP-Posting-Host: 67.112.200.144 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr13.news.prodigy.com 1026771771 ST000 67.112.200.144 (Mon, 15 Jul 2002 18:22:51 EDT) NNTP-Posting-Date: Mon, 15 Jul 2002 18:22:51 EDT Organization: Prodigy Internet http://www.prodigy.com X-UserInfo1: [[PAPDONAJUMB_LY@BCBNWX@RJ_XPDLMN@GZ_GYO^BVNDQUBLNTC@AWZWDXZXQ[K\FFSKCVM@F_N_DOBWVWG__LG@VVOIPLIGX\\BU_B@\P\PFX\B[APHTWAHDCKJF^NHD[YJAZMCY_CWG[SX\Y]^KC\HSZRWSWKGAY_PC[BQ[BXAS\F\\@DMTLFZFUE@\VL Date: Mon, 15 Jul 2002 22:22:51 GMT Xref: archiver1.google.com comp.lang.ada:27127 Date: 2002-07-15T22:22:51+00:00 List-Id: > head -> 1 -> 2 -> 3 -> null > > head := null; (to delete all elements) > or > head.next.next := null; (to delete the 3rd element) > > This would be a very bad programming technique in Pascal, because this Yes, you could do either of those assignment statements and yes you would have a "memory leak" where the tail of the list would still be occupying memory but would be inaccessible. OTOH, This_List := head; ... various uses of This_List This_List := null; would be OK since "head" would still be around to access the list, and would probably be a good idea since it would prevent someone fiddling with your list via This_List. For instance if you have changed to head->0->1->... you probably don't want someone going directly to "1" via a left over This_List. > The tutorial explains a similar procedure, called Unchecked_Deallocation, Given head->1->2... if you did an unchecked deallocation on "head" it would free the memory occupied by "1" and also set "head" to null; The 2->3->... part of the list would be allocated, but inaccessible. What you need to do is a series of unchecked deallocations, say procedure Free is new Ada.Unchecked_Deallocation(...); procedure Free_List(x : List_Pointer) is begin if x.next /= null then Free_List(x.next);end if; Free(x); end Free_List; ... Free_List(head); > but it's said that it's not recommended to use it (because some other Unchecked_Deallocation has that name because it's not checked. Thus you can really screw up, so it should be used carefully. Some systems have automatic garbage collection, but most Ada systems don't (problems with real-time timing surprises, for instance). You can get some automatic deallocation going for you with careful placement of "type ... is access ..." and especially with Storage_Pools. But mostly, with variable size array declarations and functions that can return variable size things, you find much less need for access types in Ada. You can usually do stack, rather than heap, allocation which buys automatic, safe, deallocation, and of course speed.