Re: Problems with Scope of aliased Objects

[Adam Beneschan <adam@irvine.com>]

On Apr 16, 8:59 am, "patrick.gu...@googlemail.com"
> 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?

I don't know.  That will depend on which implementation of Ada you use
and just what your performance requirements are.  If it's really a
concern, you can set up your own storage pool, with your own
allocation and deallocation routines, and tell the compiler that any
time you use "new" for certain access types, they will use that pool.
Then you can optimize the pool routines and tailor them to the
specific way you will use it (for example, if you never deallocate
anything, you can take advantage of that fact to simply the Allocate
routine; or you can organize the pool so that all objects of the same
size will be next to each other, which could lead to a more efficient
implementation).  Storage pools are explained in 13.11 of the RM, and
there may be other helpful resources, and I'm sure there are publicly
available examples of storage pools that you can use or modify---but I
don't know where they are, so hopefully someone else can point you to
them.

                              -- Adam