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: g2news1.google.com!postnews.google.com!h2g2000yqg.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 09:37:47 -0700 (PDT) Organization: http://groups.google.com Message-ID: <31f131d9-89fa-4d88-97d8-f478ab30ebdb@h2g2000yqg.googlegroups.com> References: <834db296-954d-48a8-872d-d295688066ee@c18g2000prh.googlegroups.com> <40ae6bc2-2830-429a-a8e9-81b6b7604781@o11g2000yql.googlegroups.com> <7f791896-0395-4471-910f-afaf8a488a13@r31g2000prh.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 1239899867 25855 127.0.0.1 (16 Apr 2009 16:37:47 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 16 Apr 2009 16:37:47 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: h2g2000yqg.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: g2news1.google.com comp.lang.ada:4502 Date: 2009-04-16T09:37:47-07:00 List-Id: On 16 Apr., 18:26, Adam Beneschan wrote: > 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=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 t= o > > 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? > > I don't know. =A0That will depend on which implementation of Ada you use > and just what your performance requirements are. =A0If 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). =A0Storage 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. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Adam Alright, then I think I=B4ll search some ressources concerning storage pools. I use GNAT 3.4.5 (mingw-vista special r3) with Ada95. Indeed I deal with a situation in which the dynamic-allocation is performed while initializing the software and freed when shutting it down. Thus I usually don=B4t have to deallocate the dynamically allocated memory as the runtime-system frees it at program-shutdown. This might be a starting-point for optimization. Thank you!