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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9dcaa9f073e2ef8f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!p9g2000prh.googlegroups.com!not-for-mail From: Adrian Hoe Newsgroups: comp.lang.ada Subject: Re: Type in allocator has deeper level than designated class-wide type Date: Tue, 14 Jun 2011 19:04:00 -0700 (PDT) Organization: http://groups.google.com Message-ID: <381b180e-9c83-4c6f-a5c9-3b98c2154b82@p9g2000prh.googlegroups.com> References: <9bf2ef73-5cc7-4863-90d7-2e2cf3bcd294@o10g2000prn.googlegroups.com> <92fb5bf2-f43e-4ac9-97eb-6092f10e5607@e17g2000prj.googlegroups.com> <6c4421f7-0fbd-49d0-a108-429d542608a2@h12g2000pro.googlegroups.com> NNTP-Posting-Host: 110.159.15.203 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1308103470 11412 127.0.0.1 (15 Jun 2011 02:04:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 15 Jun 2011 02:04:30 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: p9g2000prh.googlegroups.com; posting-host=110.159.15.203; posting-account=coq9PAkAAAB2Xx46RZLFJw5dY9DVXW4- User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUARLECNK X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/533.21.1 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1,gzip(gfe) Xref: g2news1.google.com comp.lang.ada:19833 Date: 2011-06-14T19:04:00-07:00 List-Id: On Jun 15, 12:01=A0am, Adam Beneschan wrote: > On Jun 14, 1:01=A0am, Adrian Hoe wrote: > > > > > But this defeats my implementation intention which the size and the > > type of its data array can only be determined during runtime. Any > > suggestion? > > There was no reason to change the generic parameters to High_Cloud, or > to change the type of the Data component from Data_Array to Item. =A0As > I tried to explain, your problem had nothing to do with arrays. =A0The > problem has to do with where the Element_Record type extension is > declared, which has to do with where the High_Cloud generic is > instantiated. =A0In your latest example, you instantiated it directly in > a library package, Hen, so there won't be a problem. =A0If you > instantiate it inside a procedure, there will be a problem. =A0But the > types of the components don't matter. > > If it *does* make a difference---i.e. if declaring Data as a > Data_Array instead of an Item makes things fail, even if High_Cloud is > still instantiated directly inside Hen---then I believe the problem is > with your compiler, and you need to contact your compiler vendor and > file a bug report. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Ad= am Yes, of course both methods are working as long as the instantiation happens at library level. The implementation of I_Array (e.g. I_Array_31 to indicate array (1..31) of Integer) in Hen gives the array a name to describe it, rather than Data_Array as in High_Cloud in the 1st post. Compiler error has been ruled out. Is there any other method other than using "generic" package? Again, the rule is: The data type and the size of the array can only be determined during runtime. Thanks. -- Adrian Hoe http://adrianhoe.com/adrianhoe