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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,894ba04cfcf20b16 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Using Controlled type objects. Date: 1996/08/01 Message-ID: #1/1 X-Deja-AN: 171448664 references: <32008E75.6A3F@ncl.ac.uk> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-08-01T00:00:00+00:00 List-Id: In article <32008E75.6A3F@ncl.ac.uk>, Andrea Coccoli wrote: >genstack.ads:#: controlled type must be declared at the library level Always instantiate your generic at library level. That is, make a library package, and put the instantiation inside it. Or, make the instantiation itself a library package. Do not instantiate your generic inside a procedure. You can then "with" the library package from your procedure Example. - Bob P.S. Lots of people seem to trip over this. The problem, I think, is that people think of the main subprogram as being "all there is", so things declared in it ought to be library level (and I'm guessing that you intended procedure Example to be the main subprogram). But in Ada, lots of things can happen after the main subprogram exits -- in particular, library tasks keep running, and the main subprogram can be recursive, or can be called from another task. But lots of programs don't have any tasks, and the only call to the main subprogram is the automatic one that happens just after elaborating the library units, so in *these* programs, it is true that locals of the main subprogram "live forever". The reason for the rule about controlled types is to prevent dangling references, and since there *might* be tasks (etc), the rule has to apply to the main subprogram just like any other subprogram. (Actually, the rule is not specific to controlled types -- it applies to any tagged type -- it's illegal if the parent is less nested than the derived type (where nesting in a package doesn't count).) And the fact that the controlled type is in a generic complicates the issue, because when you compile the generic, the compiler doesn't know whether you intend to make nested instantiations. So the error message comes out when you actually *do* the nested instantiation -- the compiler then notices that the *instance* contains an evilly-nested controlled type. Anyway, there's nothing wrong with your generic. It just happens to be the sort of generic that can't be instantiated within a procedure.