comp.lang.ada
 help / color / mirror / Atom feed
From: "Francesco Bochicchio" <bockman@virgilio.it>
Subject: Re: renames and access
Date: Thu, 12 Feb 2004 18:30:20 GMT
Date: 2004-02-12T18:30:20+00:00	[thread overview]
Message-ID: <pan.2004.02.12.18.30.06.65687@virgilio.it> (raw)
In-Reply-To: mailman.16.1076553136.295.comp.lang.ada@ada-france.org

On Wed, 11 Feb 2004 21:32:02 +0000, Stephen Leake wrote:

> "Francesco Bochicchio" <bockman@virgilio.it> 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



  reply	other threads:[~2004-02-12 18:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-11 19:15 renames and access Francesco Bochicchio
2004-02-11 22:09 ` Randy Brukardt
2004-02-12  0:02 ` Robert A Duff
2004-02-12 18:36   ` Francesco Bochicchio
2004-02-13  8:30     ` Martin Dowie
2004-02-13 20:33     ` Robert I. Eachus
2004-02-12  2:32 ` Stephen Leake
2004-02-12 18:30   ` Francesco Bochicchio [this message]
2004-02-13 19:01     ` Georg Bauhaus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox