Re: Problems with Scope of aliased Objects

[Adam Beneschan <adam@irvine.com>]

On Apr 16, 6:43 am, "patrick.gu...@googlemail.com"
<patrick.gu...@googlemail.com> wrote:
> Hi all,
> I`ve got a question concerning the scope of Ada-variables. I got the
> following situation:
> First Approach:
> - I declare a local variable "A" of type "xy" within the declaration
> part of a procedure
> - the variable-members are set and finally put into an array
> => after leaving the procedure the variables are still accessable
> through the Array which is defined on a higher scope-level
>
> Second Approach:
> Now I want to restructure my code using general Access-Types for the
> declared variables.
> - I declare a variable "refA" as an alias to my variable-type
> "xy" (also in the declaration-part of the procedure)
> - I do the same operations on "refA" I did before on "A"
> - I declare an instance of a general access-type to my variable of
> type "xy" (also in the declaration-part of the procedure)
> - I pass the access-type-Instance into the Array
> => after leaving the function, I get errors during runtime
>
> Third Approach:
> My third approach works, but uses Heap-Memory for "A" thus I generate
> the instances dynamically within my procedure and then pass the
> general access-types into my array.
>
> Now here´s my explanation for this:
> When leaving the function in my second approach the pointers are still
> avaiable, because they´re passed into the array, but the objects, the
> pointer point to are not, because they´re out of scope and thus
> destroyed. Is this rigth?

Yes.

> Anf if so, what do I have to do, to get my
> second approach running, and not losing my locally declared objects
> after leaving the function.

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