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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8c350c9f790688d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-11 16:02:26 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: renames and access Date: 11 Feb 2004 19:02:23 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1076544144 14380 192.74.137.71 (12 Feb 2004 00:02:24 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 12 Feb 2004 00:02:24 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:5462 Date: 2004-02-11T19:02:23-05:00 List-Id: "Francesco Bochicchio" writes: > Hi all, > > I have a piece of code that does something like this: > > type REC_T is record > A : Integer; > B : String(4) > end record; > > type REC_PTR_T is access REC_T; > REC_PTR : REC_PTR_T := new REC_T; > > A renames REC_PTR.A; > B renames REC_PTR.B; > > At this point, I can use A and B as if they where simple > variables. BUT, when I later reallocate the memory like this: > > function REALLOCATE_MEMORY return REC_PTR_T; > REC_PTR := REALLOCATE_MEMORY(); -- Actually, the ability to reallocate is > -- the reason for all this fuss. > -- > > then A and B still points to the old memory, not at the one currently > pointed by REC_PTR. > > Is this normal ?? Yes. You've renamed an object that no longer exists. >...(I work with ObjectADA, did not try yet with GNAT) Don't bother -- GNAT will do the same. > Is there any way to have the renames to automatically points to the new > memory? No. > If this turns impossible, what would be an equivalent solution? At the > moment, my bet is to turn the renames into access. Any better idea? Turning into access would work, but then you have to modify all the clients. But how about this: function A return Integer is begin return REC_PTR.A; end A; ? > BACKGROUND : the reason for all this is that we are trying to add a > failover capability to a very old application of many thousand lines > of code. Therefore, the 'critical variables' (one hundred or more) shall > be allocated in a special area of memory which is mirrored between the > primary machine and its backup, where a copy of the application > runs in hot standby. The trick with the renames should have spared us from > changing every line of code referring to one of these variables. > > Thanks for any hints you can give me. I recently had a similar experience. We decided that a certain abstraction should be changed, because of efficiency reasons. We couldn't just change the private part and package body; we had to change the *interface*. And that implied modifying approx 1000 lines of code in the clients. So I searhed for everywhere it was used, and fixed all the uses. This required studying the procedures called by the uses in many cases -- a big job that took a long time. But when I was done, after fixing some problems where the compiler complained, all regression tests passed, first try! No debugging. - Bob