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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,baa6871d466e5af9 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: AQ&S Guidance on pragma Elaborate_Body Date: 1997/04/21 Message-ID: #1/1 X-Deja-AN: 236337019 References: <528878564wnr@diphi.demon.co.uk> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-04-21T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote: >In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >>And this guideline is a poor one. You only need to use pragma Elaborate >>for generics named in the context clause if you instantiate the generic >>in your own elaboration code ...which is almost always the case, in my experience... >... -- and furthermore, if you *do* such an >>instantiation, use Elaborate_All, not Elaborate Agreed. Always use ELaborate_All instead of Elaborate, except when mutual recursion forces you to use Elaborate. (And, of course, use Pure, Preelaborate, or Elaborate_Body in preference to either Elab or Elab_All.) >... -- and of course this >>only applies if the generic has a body! It's best to assume that the generic has a body. The client shouldn't have to care. >I don't understand. What do you mean by elaboration code? Is it defined >as the package body, or only the begin part of the package body, ie > >with GQ; >package body P is > > package Q is new GQ (...); > >end P; > >or this > >with GQ; >package body P is >begin > declare > package Q is new GQ (...); > begin > null; > end; >end P; > >Do either of these require pragma Elaborate (or Elaborate_All)? (Assume GQ >does have a body.) Both of them do, since the instantiation is elaborated during the elaboration of P. On the other hand, if P contained: procedure Foo is package Q is new GQ... then you don't need the pragma. >And while I'm on the subject of pragma Elaborate, the Ada 83 RM stated that >that pragma was only guarenteed to work when used on a predefined package >such as Text_IO. That's a strange way to put it. Pragma Elaborate, in Adas 83 and 95, is not transitive, which is a pain, and which is why Elaborate_All was invented. It is true that Text_IO has to "work", despite the fact that pragma Elaborate is not very helpful in making it work (if Text_IO's body calls some other implementation-defined package that clients don't know about). >... Did this rule go away in Ada 95? Can I use pragma >Elaborate freely, on user-defined library units, and have a guarentee that >it will do something? The semantics of Elaborate has not changed. It will "do something" for user-defined library units -- it's just that that something is rather unhelpful. (That is, if R calls something in Q.Foo during elaboration, and Q.Foo calls somthing in P, then your abstraction is violated -- to put in exactly the "right" pragma Elaborates, either Q needs to know about its clients, or R needs to know about Q's implementation in terms of P. An Elaborate_All(Q) on R solves the problem, because it magically applies to P without R knowing about P.) - Bob