User-defined access dereference

User-defined access dereference

[Stanley R. Allen]

Language design.

In the last couple of years I've had a number of situations arise in
which it would be very convenient to be able to replace the dereferencing
of a pointer object with a function of my own.  In at least one case, I
was in enough need of doing this and knew that the dereferences were limited
to a single (but very large) package, that I felt it was worthwhile to create
a special 'dereference' function and systematically replace all implicit and
explicit uses of ".all" with a call to my function.  There were about 350
dereferences which had to be changed.  It would have been very nice and less
error-prone if it had been possible to redefine the dereference. (The error-
proneness of this change was due to the fact that, if some derefs were missed
then the code would still compile and execute since the original implicit and
explicit ".all"s were valid Ada text -- you just would not know that it failed
until it was 'too late'.)

This kind of thing has cropped up a number of times in our large, long-lived
project, because we are making heavy use of shared memory.  The package
described above was modified as stated because of the need to define pointer
values which were not really addresses, but offsets within shared memory
segments.  The dereference operation had to do more that retrieve the value;
it was necessary first to compute the actual address using the base virtual
address and the offset.  

Now we are faced with another situation in which it would be nice to replace
".all".  This time, there are over 10,000 dereferences in over a million lines
of code, so it's out of the question to do to this code what was done to the
other code before.  (The latest issue is the need to error-check each reference
because it's possible for 'remote' references to have recoverable point failures
in a what is essentially 'reflected memory' for a Linux cluster.)

I haven't been able to track down the reasons why user-defined dereferencing
was not permitted for Ada 95 (I'm guessing it was considered).  Package
System.Storage_Pools already provides the capability to define your own
storage allocation and deallocation for a particular access type, so it seems
reasonable that a user-defined dereference would also be associated with a
storage pool.

I've been trying to play with this idea for an hour or so, and came up
with this:

    Pool : A_Storage_Pool_Type;

    type Accessor is access Object;
    for Accessor'Storage_Pool use Pool;
    function De_Ref (P : in out A_Storage_Pool_Type; A : Accessor) return Object;
    for Accessor'Dereference use De_Ref;     -- not Ada 95

The compiler would recognize that all dereference operations on this type
would translate into a call to this function.

Any thoughts?

--
Stanley Allen
mailto:Stanley_R_Allen-NR@Raytheon.com

Re: User-defined access dereference

[Jeffrey Carter]

"Stanley R. Allen" wrote:
> 
> Now we are faced with another situation in which it would be nice to replace
> ".all".  This time, there are over 10,000 dereferences in over a million lines
> of code, so it's out of the question to do to this code what was done to the
> other code before.  (The latest issue is the need to error-check each reference
> because it's possible for 'remote' references to have recoverable point failures
> in a what is essentially 'reflected memory' for a Linux cluster.)
>
> Any thoughts?

I think you should make your access type private. Then any dereferences,
explicit or implicit, will be illegal, and the compiler will catch any
you miss.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail

Re: User-defined access dereference

[Dave Adlam]

Stanley R. Allen wrote in message <3B7DAEA0.60043A96@gsde.hou.us.ray.com>...
>
>Language design.
>
>
>Now we are faced with another situation in which it would be nice to
replace
>".all".  This time, there are over 10,000 dereferences in over a million
lines
>of code, so it's out of the question to do to this code what was done to
the
>other code before.  (The latest issue is the need to error-check each
reference
>because it's possible for 'remote' references to have recoverable point
failures
>in a what is essentially 'reflected memory' for a Linux cluster.)
>
>
>Any thoughts?
>
>--
>Stanley Allen
>mailto:Stanley_R_Allen-NR@Raytheon.com

I once had to integrate actual flight software for the Cluster spacecraft
into the simulator for those spacecraft.  As there were four spacecraft in
the simulator, all references to package level declarations in the flight
software had to be modified.  Most of the variables and constants were
package level!

The approach that I used (and might be useful for you) was to write a
processor that parsed the Source code and converted it into what I needed.
The parser was not a full blown language parser, just enough to let me
recognise what I needed to find and modify.  The rest of the code was output
verbatim.  I only had to work on correctly compiled code, so there was no
error handling or recovery required in the parser.

If you have a million lines of code, then a similar approach might work.
And you now have the advantages of tools like the GNAT parser and ASIS,
which should make it easier.  I would suggest that you at least look at some
form of tool to automate the conversion.

Dave Adlam

Re: User-defined access dereference

[Ted Dennison]

In article <3B7DB563.82D3F842@acm.org>, Jeffrey Carter says...
>
>"Stanley R. Allen" wrote:
>> 
>> Now we are faced with another situation in which it would be nice to replace
>> ".all".  This time, there are over 10,000 dereferences in over a million 
>> lines of code, so it's out of the question to do to this code what was done 
>
>I think you should make your access type private. Then any dereferences,
>explicit or implicit, will be illegal, and the compiler will catch any
>you miss.

I'll heartily second that. Its generally a bad idea to give folks direct
visibility inside of a record structure declared in a package spec, and this is
*exactly* why. You should be able to change the internal structure of that
"object" at will. But since you provided its clients a "help-yourself" structure
rather than a private object, you now are seriously impeeded from making any
serious structural change. (the first "you" here is plural btw. I realise it
probably wasn't Stanley who wrote this bad code) 

My advice at this point would be to make the thing private, give it the proper
interface routines, then go fix (or better yet, make the package's original
author do this) every occurance in client code that the compiler flags. Consider
it the software equivalent of having to write "I will not export public data
structures" on the blackboard 10,000 times. :-)

As Ben Franklin said, "Experience is a dear teacher..."

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com