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: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: AQ&S Guidance on pragma Elaborate_Body Date: 1997/04/21 Message-ID: <5jfu0b$l5p@top.mitre.org>#1/1 X-Deja-AN: 236357184 References: <528878564wnr@diphi.demon.co.uk> Organization: The MITRE Corporation, Bedford Mass. Newsgroups: comp.lang.ada Summary: elaborate_body or preelaborate or pure are not optional Date: 1997-04-21T00:00:00+00:00 List-Id: Bob said Pure Preelaborate Elaborate_Body Elaborate_All Elaborate > The first three make life easier, because they go on the package (rather > than on all clients), and they pretty much prevent access-before-elab > failures. One more thing must be said: in reusing this software, the reuse itself might have a circular dependency, which the compiler may or may not be able to figure out. To reduce the amount of stuff that the compiler has to worry about, and to make it possible to compute a SINGLE elaboration order (without which the program may raise program_error at will), you MUST add one of the first three to all packages you think are NOT in a circular elaboration dependency loop. Doing this also helps you identify your elaboration loops more clearly, so you can deal with them using elaborate or elaborate_all or by removing the regression testing code from the elaboration-time executable statements at the bottom of the package. Failure to add these will cause needless failures when they are reused INSIDE an elaboration dependency loop. If a quality standard says they are optional, that quality standard does not reflect the reality of Ada-95 software re-use.