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=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID, RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9bf8bfc34e223b4d X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: GNAT controlled types Date: 1998/01/27 Message-ID: <01bd2b67$04bf1760$79f482c1@xhv46.dial.pipex.com>#1/1 X-Deja-AN: 319771809 Content-Transfer-Encoding: 7bit References: <01bd2a9d$2ec16420$34fe82c1@xhv46.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Organization: UUNet UK server (post doesn't reflect views of UUNet UK) Newsgroups: comp.lang.ada Date: 1998-01-27T00:00:00+00:00 List-Id: Many thanks for the comprehensive reply. I had forgotten that the rule applies wholesale to tagged types (as it sensibly must). I have to say, with the benefit of hindsight, it might have been a better decision to implement controlled types in a different way. I feel sure that -- by means of inlining -- undue performance penalties could be avoided. It is surely inconvenient, at times, not to be able to control non-tagged types. This ability may have been considered 'dangerous' or unnecessary by the committee, but wrongly IMHO! -- Nick Roberts Croydon, UK Proprietor, ThoughtWing Software; Independent Software Development Consultant * Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 * *** Always game for a verbal joust (usually as the turkey) *** Robert A Duff wrote in article ... > It's not a special rule about controlled types (although that's what the > GNAT error message might imply). The rule is that when you have a type > extension, "type T2 is new T1 with ...", T2 must be at the same nesting > level as T1, where "nesting level" means dynamic nesting, like > procedures, tasks and the like, and not static nesting, like packages. > > The reason for the rule is to avoid dangling references. If you were > allowed to write "type T2 is new T1 with ..." inside a procedure, where > T1 is outside, then it would be possible to create an object whose tag > is T2'Tag that outlive the procedure. And then, after the procedure is > gone, call something inside it, which might reference something in that > long-gone procedure. Bad news. > > The fact that this rule applies to controlled types is to some extent an > artifact of the fact that controlled types are defined by saying "is new > [Limited_]Controlled", rather than by some special syntax. And *this* > language design decision was made to simplify implementation (and > language description). We don't need all kinds of special semantics > about controlled types -- most of it follows from the normal rules for > type extensions. Part of the issue is that the implementation can call > Finalization without constructing some more-inner context for that call.