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=2.2 required=5.0 tests=BAYES_00,HK_RANDOM_FROM, HK_RANDOM_REPLYTO,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,16e3a8dd4f3ab3f3 X-Google-Attributes: gid103376,public From: cmcknigh@hercii.lasc.lockheed.com (Chris McKnight) Subject: Re: Elaboration order Date: 1996/03/18 Message-ID: <1996Mar18.000531.25689@enterprise.rdd.lmsc.lockheed.com>#1/1 X-Deja-AN: 143231273 sender: news@enterprise.rdd.lmsc.lockheed.com (News Administrator) references: organization: Lockheed Martin Aeronautical Systems reply-to: cmcknigh@hercii.lasc.lockheed.com newsgroups: comp.lang.ada Date: 1996-03-18T00:00:00+00:00 List-Id: In article 1F9@world.std.com, bobduff@world.std.com (Robert A Duff) writes: >In article , >Robert I. Eachus wrote: >> BUT, and this is what makes it so painless, either your program >>runs or you get PROGRAM_ERROR right off the bat, so leaving out a >>(potentially) required pragma Elaborate is pretty harmless. > >True during development on a particular platform. But what bugs me >about these rules is that the mysterious Program_Error can pop up when >you port the program to a different compiler. (Or, less likely, a new >version of the same compiler.) ... or when you add new functionality on the same platform either during incremental development or maintenance. It is not uncommon for a program to suddenly develop elaboration order problems simply by recompiling a library unit or two, even if that unit does not itself have the problem. I've seen this several times, the compilation causes a change in the elaboration order which causes a side effect of making some other library unit get an elaboration order problem. And, since we're talking Ada 83 here, it can be difficult to track down the possibly nested library units to which you'll need to add pragma Elaborate. So, as you can see, using subprogram calls during declarative regions can be far from painless. These type of problems have lead me to avoid assignments during elaboration using subprogram calls. Why invite trouble when it's easily avoided? I'll take controlled behaviour of initialization through Initialization procedures over unpredictable elaboration order dependencies any day. Just my $.02 Cheers, Chris