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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8c350c9f790688d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-12 10:30:22 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!peernews3.colt.net!newsfeed.stueberl.de!news-out.tin.it!news-in.tin.it!news3.tin.it.POSTED!not-for-mail From: "Francesco Bochicchio" Subject: Re: renames and access User-Agent: Pan/0.13.0 (The whole remains beautiful (Debian GNU/Linux)) Message-ID: Newsgroups: comp.lang.ada References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Date: Thu, 12 Feb 2004 18:30:20 GMT NNTP-Posting-Host: 80.116.219.64 X-Complaints-To: newsmaster@tin.it X-Trace: news3.tin.it 1076610620 80.116.219.64 (Thu, 12 Feb 2004 19:30:20 MET) NNTP-Posting-Date: Thu, 12 Feb 2004 19:30:20 MET Organization: TIN Xref: archiver1.google.com comp.lang.ada:5492 Date: 2004-02-12T18:30:20+00:00 List-Id: On Wed, 11 Feb 2004 21:32:02 +0000, Stephen Leake wrote: > "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. The result of the rename statements is cached. > >> Is there any way >> to have the renames to automatically points to the new memory? > > You have to evaluate them again after you change Rec_Ptr: > > loop > rec_ptr := Reallocate_Memory; > declare > a : Integer renames REc_ptr.a; > b : string (4) renames REc_Ptr.b; > begin > ... > end; > end loop > This was a nice idea, but not enough. I tried that: only the code in the declare block see the new renames. Code in functions defined before the declare block continues to see the old renames, also if the function is called inside the declare block. Same goes for other packages or other tasks (as I said, it is very old code, badly written, and the use of global variables is pervasive). >> 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. > > Change the variables into equivalently named functions, whose bodies > reference the pointer. I though of that, but this is real-time software and I would prefer not to add an extra function call every time one of these variables (which happens very often in the processing loop ). We already have performance concerns with the code as it is. Also, if I use function returning pointers, like this: type INTEGER_P is access all INTEGER; function A returns INGEGER_P is begin return REC_PTR.A'access; end A; then I still have to change code like this: A := 3; into: A.all := 3. which is the same effort that writing: REC_PTR.A := 3; which is what I'm trying to avoid, since I would have to search and modify all critical variable usage in about 40000 lines of code (but I'm starting to think that there is no way to avoid it). Thanks anyway, also to the others that answered. Ciao ----- FB