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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,72113392dc4997bd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-17 20:00:55 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!claveman From: claveman@grzorgenplatz.net (Charles H. Sampson) Newsgroups: comp.lang.ada Subject: Re: Subprogram Pointer in a Generic Date: Thu, 17 Apr 2003 19:59:05 -0700 Organization: NetHere Inc. Message-ID: <1ftksnp.1y04fz71feqliuN%claveman@grzorgenplatz.net> References: <1ftiuys.1twhum2q9qa00N%claveman@grzorgenplatz.net> User-Agent: MacSOUP/2.4.6 Cache-Post-Path: news-1.nethere.net!unknown@ppp-207-167-100-212.sndg-pm4-2.dialup.nethere.net X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:36270 Date: 2003-04-17T19:59:05-07:00 List-Id: Samuel Tardieu wrote: > Charles H. Sampson wrote: > > > There are two questions. (1) What are they trying to prevent by > > this restriction? (2) Is there a more robust way of working around it? > > (1) The absence of such a rule would prevent an implementation from > implementing efficiently shared generic packages: if, from > within the body, you take a reference to a local subprogram, > you do not statically know the accessibility "depth", as the > generic package may be instantiated locally (from within a > subprogram for example). Note that building the access value > from outside the generic package then storing it is subject to > the classical static accessibility rules and thus does not > require this restriction. That explains the reason for the rule, I think, but the rule invalidates one of the long-established folk properties of generics, that an instantiation of a generic has the same properties as if the thing (package or subprogram) had been written out in full. I'm not up on the shared code of generics but I think you're saying something like this. With shared code in effect, each call into a package instantiation causes the instantiation's data spaces to be set up. If this is the case, then what I want to do wouldn't work because when the ultimate call on the local procedure is made the setting up of the data space wouldn't occur because it is a local procedure. Whatever the mechanism, it seems that there is a solution that would give me what I want. The instantiation must be able to handle the case where the subject procedure, the one to which 'Access is applied, is declared in the specification of the generic package. That procedure can be called both from outside the package and from within. So, whatever the mechanism for code sharing in generics, all the compiler has to do is handle the local procedure as though it were also declared in the specification. > > However, I must admit that I do not understand why it is not > sufficient for the access to subprogram type to be declared in the > corresponding generic declaration, as both accessibility levels can > be statically compared when compiling the generic package body. > > Should this restriction be alleviated in Ada 2005? I think so, not only for my particular application but so the folk property would be true again. > > (2) If you *know* that you can safely use such a reference, use > your (non portable) compiler-provided attribute ('Unrestricted_Access > for GNAT) to create the access value. Another solution would > be to export the subprogram if not done already and build the > access value from outside. The problem with the first suggestion is that I'm trying to come up with a portable solution, so use of a compiler-specific attribute isn't going to help. Besides, not all compilers have such attributes. The second suggestion is an acceptable one. Talk about not seeing the obvious! I'm trying to solve a very application-specific problem with this registration process. My "solution" had a nice side-effect that the subject procedures didn't have to be made global when their scope of use is very small. However, making them global and getting fully portable code is far better than the kludge I came up with. Charlie -- For an email response, my real user name is csampson and my ISP is inetworld.net.