Re: 4 beginner's questions on the PL Ada

[Alan Jump <alan.jump@gmail.com>]

On Friday, August 9, 2013 4:33:51 PM UTC-7, Adam Beneschan wrote:

> No.  First of all, if you do this on other record types:
> 
> 
>    X := new Record1;
>    X := new Record1;
>    X := new Record1;
> 
> the memory allocated for the first Record1 doesn't get released when the second X is allocated, and so on.  The data is still there in memory.  And it needs to be, in case there was some code in between those allocations that caused something else to point to the record (or to one of its components) in between.  You can't automatically destroy the record objects if something else might be pointing to them.
> 
> But even if nothing else was pointing to them (as in the above example), Ada still doesn't mandate garbage collection--i.e. reclaiming storage that nothing points to.  A compiler *could* generate code to do this automatically, but I don't know of any that do.  Generally, you have to do your own memory management (using Unchecked_Deallocation).  So if you can see that in the above example, memory storage won't automatically be reclaimed, you can see by analogy that tasks won't automatically be terminated either.  
> 
> But there's another factor: if you allocate a task (or a record containing a task), using Unchecked_Deallocation (or automatic memory reclamation) won't terminate the task.  That's just the way the language authors decided.  This discussion has come up before, and it's surprised other people that a task will still run after Unchecked_Deallocation has been used on it, but there were reasons why things are the way they are.  I don't remember the reasons, though. 
> 
>                              -- Adam

So what you have shown here is a classic recipe for a memory leak. That strikes me as poor code design in any language. I was given Java as a first OO language, so maybe that's what spoiled me on memory reclamation, but I still tried to avoid reusing variables unless I was absolutely certain that what I was writing was going to remain in a limited scope.

Turning back to the point at hand, it seems to me that a better example would have been to allocate an array of task types, then examine the 'Image(Current_Task). But then, if one did produce the array of task types, one would then use the array index as the unique task name, yes?

Pardon me whilst I wander off to find more coffee. Something tells me I'm going to need it.

 - -
73 de N5ILN
Alan