Re: Problems with Scope of aliased Objects

["patrick.gunia@googlemail.com" <patrick.gunia@googlemail.com>]

> This is impossible (unless I am completely misunderstanding what
> you're trying to do).  When you leave a function, any locally declared
> objects (objects declared in the declarative part of the function) are
> lost, period.  It sounds like you may not be aware of how local
> variables are implemented in a typical implementation.  But when a
> function or procedure starts, it will allocate a certain amount of
> memory space on the stack, which it uses for local variables.  When it
> returns, the stack pointer is set back to what it was before, and the
> stack space can then be reused for the local variables belonging to a
> *different* function or procedure (as well as for other information
> that the processor leaves on the stack).  That means that the memory
> for the local variables you used for the first procedure will get
> overwritten, and the accesses that you've set up to point to those
> local variables become useless.  That's why your second approach got
> errors; the Ada language has built-in checks to prevent you from doing
> something like this.
>
> Using heap memory (the third approach) is what you'll need to do.  If
> you have some objection to using heap memory or some problem you think
> it would cause, please let us know what the problem is, and we should
> be able to help you figure out what Ada features exist to alleviate
> the problem.
>
>                                -- Adam

Alright, this was my explanation. I forgot the fact, that the values
are copied into the array. The simple reason why I didn´t want to use
heap-memory is the performance-aspect. My third approach works using
"new" to allocate heap-memory dynamically. In this case, adding the
access-type into the array leads to a copy of the heap-memory-adress
where the object was created. This address is copied into the array
and thus still reachable. To cut a long story short, my second
approach simply won´t work because of dangling pointers which point to
memory which isn´t assigned any longer (at least not to the objects I
expect to be there). Do I have to be afraid of runtime-performance-
problems when using dynamic allocation in Ada?