comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Instantiation problem in generic.
Date: Tue, 22 Jul 2003 13:26:38 -0500
Date: 2003-07-22T13:26:38-05:00	[thread overview]
Message-ID: <vhr0bunl33du36@corp.supernews.com> (raw)
In-Reply-To: pan.2003.07.22.09.33.50.152323@mail.utexas.edu

"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.






      reply	other threads:[~2003-07-22 18:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-22  9:33 Instantiation problem in generic Bobby D. Bryant
2003-07-22 18:26 ` Randy Brukardt [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox