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-18 11:23:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!mango.news.easynet.net!easynet.net!proxad.net!proxad.net!newspeer1-gui.server.ntli.net!ntli.net!newsfep2-win.server.ntli.net.POSTED!53ab2750!not-for-mail From: "chris.danx" Newsgroups: comp.lang.ada References: Subject: Re: access / freeing memory X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Thu, 18 Jul 2002 19:22:38 +0100 NNTP-Posting-Host: 80.5.140.234 X-Complaints-To: abuse@ntlworld.com X-Trace: newsfep2-win.server.ntli.net 1027016592 80.5.140.234 (Thu, 18 Jul 2002 19:23:12 BST) NNTP-Posting-Date: Thu, 18 Jul 2002 19:23:12 BST Organization: ntl Cablemodem News Service Xref: archiver1.google.com comp.lang.ada:27235 Date: 2002-07-18T19:22:38+01:00 List-Id: "Jan Prazak" wrote in message news:pan.2002.07.15.23.51.51.725321.2066@gmx.net... > Hello, > > I have finished reading one Ada tutorial (I won't say that I did > understand everything), but the section about "access" was not very > clearly explained. > > Just imagine this simple situation: > I have a single-linked list, with a "head". > > head -> 1 -> 2 -> 3 -> null > > Is it really possible to say > > head := null; (to delete all elements) > > or > > head.next.next := null; (to delete the 3rd element) > > or similar things??? How do you know that head.next.next exists? > This would be a very bad programming technique in Pascal, because this > would create a "memory hole". There each element has to be "disposed" with > a procedure called "Dispose". See other ppls replies about unchecked_deallocation. > The tutorial explains a similar procedure, called Unchecked_Deallocation, > but it's said that it's not recommended to use it (because some other > access type could access that memory address (that's clear)). > So does the operating system take care of the deallocation? > And what about other OSs than Linux? Or has this to do with the Ada > compiler, which maintains the memory (de)allocation? (This would be more > logical.) Other ppls replies don't seem to be helping. Let me try and clear a few things up. This is general and concerns memory management which may vary between compilers, so this may not be what GNAT does, but you'll get the idea! Firstly, when you create an object via 'new' it is allocated and initialised. Usually a call to new will typically take memory from the heap, this is an area of memory typically used for dynamic memory management. The heap is usually within your program, and the compiler will insert code to manage it. When you do head.next := null, what are you really doing? You are saying head.next is null, not that the node at head.next is, and since the node is allocated on the heap, it still exists within the heap but is potentially no longer accessable to the program. If the compiler employs garbage collection the node will be removed, but garbage collection isn't there yet, so we'll neglect it and focus on non-garbage collected compilers (you can still do this on GC collected compilers, it's probably not a good idea to rely on the compiler to do things for you all the time). How does the heap know it can use the memory again unless we tell it? (the heap doesn't know how many variables point to a particular item within in it, only that some memory is associated with the item). We use unchecked_deallocation to tell the heap the memory isn't in use anymore. Let's think about a singly linked list with the following setup. - each node is a record containing an item and a pointer to the next item. - each list is a record containing a pointer to the first item and a variable recording the number of items in the list - a position points to a node within the list (it could be a record, or simply an access type). If you want to deallocate a node at a given position, we need to first find the node preceding the one at position. Then we need to adjust that node we found to skip over the node at position (what follows position?). Now none of the items in the list point to the node we wish to deallocated, but we still know where it is in the heap since position records this (the position is invisible to the programmer, who only knows it exists or it doesn't -- well in Ada anyway). We can now deallocate the node at position by calling unchecked_deallocation, and adjust the number of items in the list. Then position points to nothing (null) and the heap knows the memory is free for reuse. That's basically it. It's worth noting that above you might get the impression that the heap is a structure, but it doesn't have to be, and you can still think of it as above with little loss regardless of how it's actually done in practise. HTH, Chris p.s. why do ppl mention things like Storage_Pools to newbies? It only confuses them and makes things harder!