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,7f2ce8bda9cae4ab X-Google-Attributes: gid103376,public Path: controlnews3.google.com!news1.google.com!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread1.news.pas.earthlink.net.POSTED!a6202946!not-for-mail From: Jeffrey Carter Organization: jrcarter commercial-at acm [period | full stop] org User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: "Must instantiate controlled types at library level." Why? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 12 May 2004 01:03:41 GMT NNTP-Posting-Host: 63.184.17.249 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.news.pas.earthlink.net 1084323821 63.184.17.249 (Tue, 11 May 2004 18:03:41 PDT) NNTP-Posting-Date: Tue, 11 May 2004 18:03:41 PDT Xref: controlnews3.google.com comp.lang.ada:460 Date: 2004-05-12T01:03:41+00:00 List-Id: Peter C. Chapin wrote: > I have a generic package that contains a controlled type. When I attempt to > instantiate that package in the declarative part of a procedure, GNAT > (v3.15p) tells me that I must instantiate controlled types at "library > level" (or something like that). I worked around this by creating a helper > package in which I did the instantiation and then used that helper package in > my procedure. However, this experience leads me to wonder why there is this > restriction on controlled types. That's the correct way to create a controlled type. I know it's difficult to see why this is needed, but it's a feature of all tagged types, not just controlled types. Any tagged type declared at library level must be extended at library level. The declarative part of a subprogram, including a library level subprogram, is never at library level. The problem is that a value of an extended type can be stored in a variable at a higher nesting level. This could result in dispatching to an operation that no longer exists and referencing variables that no longer exist. This is easier to demonstrate than describe: package Library_Level is type Taggy is tagged null record; procedure Op (T : in out Taggy); type Taggy_Ptr is access all Taggy'Class; Ptr : Taggy_Ptr; end Library_Level; with Library_Level; procedure Outer is procedure Inner is type Taggy_Ext is new Library_Level.Taggy with null record; -- Illegal type extension procedure Op (T : in out Taggy_Ext); I : Integer := 7; procedure Op (T : in out Taggy_Ext) is begin -- Op I := I + 1; end Op; V : Taggy_Ext; begin -- Inner Library_Level.Ptr := new Library_Level.Taggy'Class'(V); end Inner; begin -- Outer Inner; Library_Level.Op (T => Library_Level.Ptr.all); end Outer; The call to Library_Level.Op would attempt to dispatch to Outer.Inner.Op, which is out of scope. The references to I in Outer.Inner.Op refer to a variable that no longer exists. -- Jeff Carter "Blessed is just about anyone with a vested interest in the status quo." Monty Python's Life of Brian 73