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 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!r31g2000prh.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Problems with Scope of aliased Objects Date: Thu, 16 Apr 2009 09:26:17 -0700 (PDT) Organization: http://groups.google.com Message-ID: <7f791896-0395-4471-910f-afaf8a488a13@r31g2000prh.googlegroups.com> References: <834db296-954d-48a8-872d-d295688066ee@c18g2000prh.googlegroups.com> <40ae6bc2-2830-429a-a8e9-81b6b7604781@o11g2000yql.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1239899177 23501 127.0.0.1 (16 Apr 2009 16:26:17 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 16 Apr 2009 16:26:17 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: r31g2000prh.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:4501 Date: 2009-04-16T09:26:17-07:00 List-Id: 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 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? 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