Re: renames and access

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"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.  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