From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ab46f8fd8bc30c31 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!o11g2000yql.googlegroups.com!not-for-mail From: "patrick.gunia@googlemail.com" Newsgroups: comp.lang.ada Subject: Re: Problems with Scope of aliased Objects Date: Thu, 16 Apr 2009 08:59:58 -0700 (PDT) Organization: http://groups.google.com Message-ID: <40ae6bc2-2830-429a-a8e9-81b6b7604781@o11g2000yql.googlegroups.com> References: <834db296-954d-48a8-872d-d295688066ee@c18g2000prh.googlegroups.com> NNTP-Posting-Host: 78.34.66.221 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1239897623 18550 127.0.0.1 (16 Apr 2009 16:00:23 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 16 Apr 2009 16:00:23 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: o11g2000yql.googlegroups.com; posting-host=78.34.66.221; posting-account=D7TrwwoAAAAVyN71CASRiSp392RIjlsB User-Agent: G2/1.0 X-HTTP-UserAgent: Opera/9.64 (Windows NT 6.0; U; de) Presto/2.1.1,gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:5469 Date: 2009-04-16T08:59:58-07:00 List-Id: > This is impossible (unless I am completely misunderstanding what > you're trying to do). =A0When you leave a function, any locally declared > objects (objects declared in the declarative part of the function) are > lost, period. =A0It sounds like you may not be aware of how local > variables are implemented in a typical implementation. =A0But when a > function or procedure starts, it will allocate a certain amount of > memory space on the stack, which it uses for local variables. =A0When 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). =A0That 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. =A0That'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. =A0If > 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. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Adam Alright, this was my explanation. I forgot the fact, that the values are copied into the array. The simple reason why I didn=B4t 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=B4t work because of dangling pointers which point to memory which isn=B4t 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?