Instantiation problem in generic.

Instantiation problem in generic.

[Bobby D. Bryant]

Am I interpreting this GNAT message correctly? (the compiler is GNAT 3.15p)

For the code in the body of a generic library package (pardon the
wrapping) -

-- Set up callbacks for the window manager's decorations:
GTK_Stuff.Widget_Callback_Returning_Boolean.Connect
   (Widget => Histogram_Window,
    Name   => "delete_event",
    Marsh  => GTK_Stuff.Widget_Callback_Returning_Boolean.To_Marshaller
                 (Close_Histogram_Window_Fn'Access));
--
GTK_Stuff.Widget_Callback.Connect
   (Widget => Histogram_Window,
    Name   => "destroy",
    Marsh  => GTK_Stuff.Widget_Callback.To_Marshaller
                 (Close_Histogram_Window'Access));

I get error messages when compiling the package body (line numbers off due
to Usenet wrapping) -

746. Marsh  => GTK_Stuff.Widget_Callback_Returning_Boolean.To_Marshaller
                  (Close_Histogram_Window_Fn'Access));
        >>> access type must not be outside generic body

750. Marsh  => GTK_Stuff.Widget_Callback.To_Marshaller
                  (Close_Histogram_Window'Access));
        >>> access type must not be outside generic body

The Close_Histogram_* subprograms are defined within the body of the
generic package, so I don't understand what the compiler is complaining
about.

If I put declarations in the package spec, whether in the public area or
the private area, the message is suppressed when compiling the package,
but it still occurs when compiling the program that instantiates it.

Any suggestions?

-- 
Bobby Bryant
Austin, Texas

Re: Instantiation problem in generic.

[Randy Brukardt]

"Bobby D. Bryant" <bdbryant@mail.utexas.edu> wrote in message
news:pan.2003.07.22.09.33.50.152323@mail.utexas.edu...
>
> Am I interpreting this GNAT message correctly? (the compiler is GNAT
3.15p)
>
> For the code in the body of a generic library package (pardon the
> wrapping) -
>
> -- Set up callbacks for the window manager's decorations:
> GTK_Stuff.Widget_Callback_Returning_Boolean.Connect
>    (Widget => Histogram_Window,
>     Name   => "delete_event",
>     Marsh  => GTK_Stuff.Widget_Callback_Returning_Boolean.To_Marshaller
>                  (Close_Histogram_Window_Fn'Access));
> --
> GTK_Stuff.Widget_Callback.Connect
>    (Widget => Histogram_Window,
>     Name   => "destroy",
>     Marsh  => GTK_Stuff.Widget_Callback.To_Marshaller
>                  (Close_Histogram_Window'Access));
>
> I get error messages when compiling the package body (line numbers off due
> to Usenet wrapping) -
>
> 746. Marsh  => GTK_Stuff.Widget_Callback_Returning_Boolean.To_Marshaller
>                   (Close_Histogram_Window_Fn'Access));
>         >>> access type must not be outside generic body
>
> 750. Marsh  => GTK_Stuff.Widget_Callback.To_Marshaller
>                   (Close_Histogram_Window'Access));
>         >>> access type must not be outside generic body

As usual, GNAT error messages are pretty good: in this case, it says exactly
what the error is:
"access TYPE (of the 'access) must not be outside generic body".

3.10.2(32) says: "If the subprogram denoted by P is declared within a
generic body, S
shall be declared within the generic body." In this case P is
Close_Histogram_Window, and S is the type of Close_Histogram_Window'Access.

This rule was relaxed a bit by AI-229, which also fixes a hole (it is
possible for there to be dangling references), but I don't know whether GNAT
implements that AI or not.

Besides dangling references, these rule also make generic sharing practical
(it is not possible to generate working code for a 'Access of a subprogram
in a generic body, unless ALL subprogram accesses assumed that they had
generic sharing parameters. That would be a nasty distributed overhead, and
would make it impossible to pass access-to-subprogram types to C).

Since you didn't give the entire program, I can't suggest a work-around. The
usual work around is to declare the 'Access in the private part of the
generic unit:

      CHW_Ptr : constant <Whatever> := Close_Histogram_Window'Access;

BTW, the new wording for 3.10.2(32) is: "If the subprogram denoted by P is
declared within a generic unit, and the expression P'Access occurs within
the body of that generic unit or within the body of a generic unit declared
within the declarative region of the generic, then the ultimate ancestor of
S shall be a non-formal type declared within the generic unit." It is best
to meet both rules for now, because compilers may not change until the
Amendment comes out, but could change immediately.

                          Randy.