Re: Subprogram Pointer in a Generic

[claveman@grzorgenplatz.net (Charles H. Sampson)]

Samuel Tardieu <sam@rfc1149.net> 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.