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-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3a414836333dfef7
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-01-04 07:03:25 PST
Path: 
 archiver1.google.com!news1.google.com!sn-xit-02!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Matthew Heaney" <mheaney@on2.com>
Newsgroups: comp.lang.ada
Subject: Re: Elaboration in GNAT
Date: Fri, 4 Jan 2002 10:07:45 -0500
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <u3bh1tiuppk9c7@corp.supernews.com>
References: <1006952193.650930@edh3>
 <5ee5b646.0111281125.7e9fbca3@posting.google.com> <1010151875.216658@edh3>
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Complaints-To: newsabuse@supernews.com
Xref: archiver1.google.com comp.lang.ada:18526
Date: 2002-01-04T10:07:45-05:00
List-Id: <comp.lang.ada>


"Frode Tenneboe" <ft@edh.ericsson.se> wrote in message
news:1010151875.216658@edh3...
> Robert Dewar <dewar@gnat.com> wrote:
> > If this message is not intelligible, I recommend reading
> > the entire chapter on elaboration issues in the users
> > guide. Elaboration is certainly a tricky issue, and
> > generally you should not turn on -gnatwl unless you know
> > what you are doing.

I'm not sure I agree with Robert's advice here.  I always use -gnatwl.

If you don't know what you're doing, then the best way to learn is to write
some programs and submit them to the compiler!

> The code is legacy code with complex dependencies and need some time
> to grow..... The warning is removed by adding (in the above example):
>
> pragma Elaborate_Body(bar)
>
> in bar.ads.
>
> However, I'm still not totatlly sure if this is the "correct"
> approach. But at least it makes more sense than adding
> pragma Elaborate_All in all clients using package bar.

My advice is to always use a categorization pragma in a package declaration,
and to use the strongest categorization possible, ie

1) pragma Pure;
2) pragma Preelaborate;
3) pragma Elaborate_Body;

The one time you cannot use a categorization pragma (say, Elaborate_Body) is
when a package withs its own children, which means a client will have to use
pragma Elaborate_All (if it needs to call operations in that package during
its own elaboration).

However, I prefer to restructure the parent package by moving the
child-dependent stuff into a new child, and then have that new child with
its siblings.  That makes it possible to say pragma Elaborate_Body in the
parent.

This comes up with you declare a "protocol class" (an abstract tagged type)
with a constructor to return a concrete type in the class:

package P is

   pragma Elaborate_Body; --illegal

   type T is abstract tagged limited null record;
   procedure Op (O : access T) is abstract;

   type T_Class_Access is access all T'Class;
   function New_T (S: String) return T_Class_Access;

end;

package P.C is
   type NT is new T with null record;
   procedure Op (O : access NT);
end;

with P.C;
package body P is
   function New_T (S : String) return T_Class_Acceess is
   begin
      return new P.C.NT;
   end;
end;

You can't use pragma Elaborate_Body in P, because the body of P withs its
own child P.C.  But the workaround is easy enough: simply declare the
constructor as a child of P:

function P.New_T (S : String) return T_Class_Access;

with P.C;
function P.New_T (S : String) return T_Class_Access is
begin
   return new P.C.NT;
end;

Now you can use pragma Elaborate_Body for P, because the body of P no longer
withs any of its children.