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,FREEMAIL_FROM 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-22 23:15:28 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: kcline17@hotmail.com (Kevin Cline) Newsgroups: comp.lang.ada Subject: Re: access / freeing memory Date: 22 Jul 2002 23:15:28 -0700 Organization: http://groups.google.com/ Message-ID: References: <%WHY8.1173$tt5.52024504@newssvr13.news.prodigy.com> NNTP-Posting-Host: 192.76.70.227 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1027404928 9288 127.0.0.1 (23 Jul 2002 06:15:28 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 23 Jul 2002 06:15:28 GMT Xref: archiver1.google.com comp.lang.ada:27327 Date: 2002-07-23T06:15:28+00:00 List-Id: tmoran@acm.org wrote in message news:<%WHY8.1173$tt5.52024504@newssvr13.news.prodigy.com>... > > 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. I find statements like this rather naive. It implies that Ada programmers have little need for any data structure more complex than an array, and I don't understand why this belief seems to be so widely promulgated. Although Ada supports arrays particularly well, for most problems use of associative containers leads to a simpler solution. It's unfortunate that the Ada community never adopted a high-quality standard container library. The lack of such a library increases the start-up cost of an Ada project -- libraries have to be located and evaluated or written anew. The result is that things that should be easy become difficult, and developers who try Ada become frustrated and move on.