Re: Problems with Scope of aliased Objects

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?
.

Relevant Pages

  • Re: when to use "new"
    ... Maybe you should understand what the stack is and what the heap is. ... the memory for local variables are ...
    (comp.lang.cpp)
  • Re: Macros
    ... >> stack?) ... > they do not depend on the sizes or number of local variables (just their ... The CPU is more efficient when it uses the closest L1 cache ... > You can reproduce this scheme for main memory and pagefile: ...
    (microsoft.public.vc.language)
  • Re: Buffer over-run vulnerabilities
    ... Any data beyond the length of the buffer "spills ... > over" into the memory following the buffer, ... fn's local variables in the stack and so splats over memory allocated to ... referenced using an offset from the base of their area, and local variables ...
    (comp.os.linux)
  • Re: Memories
    ... You know it accesses memory through addresses, ... Local variables go on the stack. ... mallocallocates memory from the heap. ...
    (comp.lang.c)
  • Re: If Macs have no spyware....
    ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
    (comp.sys.mac.advocacy)