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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,530474eb5e6fefe1 X-Google-Attributes: gid103376,public From: "Raymond C. Rawa" Subject: Re: using 'address to make indrect calls Date: 1999/07/01 Message-ID: <377B929F.5B79@nospam.boeing.com>#1/1 X-Deja-AN: 496081300 Content-Transfer-Encoding: 7bit Sender: nntp@news.boeing.com (Boeing NNTP News Access) X-Nntp-Posting-Host: mac-herbert.he.boeing.com References: <3779194C.45EA@b.com> <377A5A93.AB271D47@magic.fr> Content-Type: text/plain; charset=us-ascii Organization: The Boeing Company Mime-Version: 1.0 Reply-To: Raymond.C.Rawa@nospam.boeing.com Newsgroups: comp.lang.ada Date: 1999-07-01T00:00:00+00:00 List-Id: Pascal MALAISE wrote: > The instanciation in make within a procedure/function. > The validity of the instanciated objects ends when the procedure ends. > Suppose G_PKG declares objects (variables, procedures) and test stores > the address of such object in a "global", remanent variable (in a > package spec): > other_package.g_object_address := g.object'address > the using other_package.g_object_address after the end of g leeds to > unpredicable result. > The compiler does not know that test is your main procedure. Neither do > I, > but I suppose, and in this case (test is the "main") there is no danger. > > If you want to get rid of the warning: > with G_PKG; > package g is new G_PKG; > > with g; > procedure test is > > Then the instanciation is more "static". Thank you, for your help. Your solution worked like a charm for the test case. Alas, the test case I proposed is too simplistic. In my actual application, the generic package is instantiated within a package body, not a procedure. Here's what I'm really trying to do... (1) I've got a task out there that receives procedure addresses and attempts to execute them in it's thread of control. (2) I've got a bunch of packages out there that send callback procedure addresses to the task. The first two seem to work just fine, here's the complication... (3) Some packages need to pass a parameter to the callback routines. The task only handles parameterless procedures. (4) So I've created a generic package that can be instanciated with the desired parameter type. It contains two procedures. procedure Call_Procedure_With_Parameter( Procedure_Address : SYSTEM.Address; Parameter : Parameter_Type; -- places Procedure_Address and Parameter into a queue. -- passes Call_Queued_Procedure'address to the above mentioned task. procedure Call_Queued_Procedure; -- pop's an address and parameter off the queue -- executes the procedure located at Procedure_Address with Parameter (5) Now any package that needs to pass parameters to it's callback routine can simply instanciate my generic with the desired type and execute the Call_Procedure_With_Parameter routine. My problem seems to be that the compiler doesn't know that the procedure address specified in the generic package is valid, so it produces a warning message. I guess as long as I instanciate the generic package at either the library level or within a package or procedure that is elaborated at the library level I'm fine. I just wish I could supress that darn warning. Raymond C. Rawa V-22 Operational Software IPT Digital Map Software Designer Raymond.C.Rawa@Boeing.com Oh by the way, I'm stuck in Ada83