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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,23dabf88feae3dba X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Elaboration worries Date: 21 Jun 2006 19:07:11 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <4fssh9F1ena5jU1@individual.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1150931232 320 192.74.137.71 (21 Jun 2006 23:07:11 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 21 Jun 2006 23:07:11 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news2.google.com comp.lang.ada:4887 Date: 2006-06-21T19:07:11-04:00 List-Id: "Alex R. Mosteo" writes: > a) make your package Pure. > b) if not possible, make it Preelaborate. > c) if not possible, put an Elaborate_Body in the spec. > > I was happy following this rule, but just recently I've started to > experiment with the -gnatwl switch, that warns when a "Elaborate_All" is > needed. I have two questions related with this. > > The first one is that I don't really grasp why a "Elaborate_All" could be > needed if one strictly follows the tree rules above. I don't think you can follow those three rules in all cases, because they place restrictions on the code you can write. For example, Elab_Body prevents a package body from with-ing its children. There's a good description of elab issues in the GNAT docs. > The second one is this: by my observation of the gnat warnings, it seems > that the requirement for "Elaborate_All" is a "server side" one. However, I > must use the E_A in all "client side" units. This is because contrarily to > the abc) rule pragmas, that can refer to the package where they appear, E_A > can not. Yes, that is a pain. > Example: Package A causes a warning for E_A in all packages that use > A. No -- only if they use A at elaboration time. >... I > can't do nothing at A to remove the warning, but to put an E_A(A) in all > client packages. This seems strange to me. Yes, it is strange. > A final note is that this second situation happens to me mostly with generic > units. Yes, that's because generic instantiations are usually at library level, and are therefore elaborated at library package elab time. - Bob