comp.lang.ada
 help / color / mirror / Atom feed
From: "chris.danx" <spamoff.danx@ntlworld.com>
Subject: Re: access / freeing memory
Date: Thu, 18 Jul 2002 19:22:38 +0100
Date: 2002-07-18T19:22:38+01:00	[thread overview]
Message-ID: <kIDZ8.16625$Zl6.445091@newsfep2-win.server.ntli.net> (raw)
In-Reply-To: pan.2002.07.15.23.51.51.725321.2066@gmx.net


"Jan Prazak" <janp9@gmx.net> 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!





  parent reply	other threads:[~2002-07-18 18:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-16  0:52 access / freeing memory Jan Prazak
2002-07-15 22:22 ` tmoran
2002-07-16 13:54   ` Jan Prazak
2002-07-16 11:51     ` Fabien Garcia
2002-07-16 22:59       ` Jan Prazak
2002-07-16 15:42     ` Darren New
2002-07-16 22:59       ` Jan Prazak
2002-07-17  5:22         ` Simon Wright
2002-07-17 21:36           ` Jan Prazak
2002-07-24  0:25       ` David Thompson
2002-07-23  6:15   ` Kevin Cline
2002-07-18 18:22 ` chris.danx [this message]
2002-07-19 13:32   ` Jan Prazak
2002-07-19 23:50     ` chris.danx
     [not found] <mailman.1026804243.16337.comp.lang.ada@ada.eu.org>
2002-07-19  1:42 ` Robert A Duff
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox