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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8435c6357dfc5329,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-17 16:54:10 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!cyclone.swbell.net!bos-service1.ext.raytheon.com!dfw-service2.ext.raytheon.com.POSTED!not-for-mail Message-ID: <3B7DAEA0.60043A96@gsde.hou.us.ray.com> From: "Stanley R. Allen" Reply-To: Stanley_R_Allen-NR@Raytheon.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-2.14.10smp i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: User-defined access dereference Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 17 Aug 2001 18:54:08 -0500 NNTP-Posting-Host: 192.27.47.71 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.raytheon.com 998092449 192.27.47.71 (Fri, 17 Aug 2001 18:54:09 CDT) NNTP-Posting-Date: Fri, 17 Aug 2001 18:54:09 CDT Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:12083 Date: 2001-08-17T18:54:08-05:00 List-Id: 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