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.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f6b6181765c24743 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-02-07 07:00:13 PST Path: supernews.google.com!sn-xit-02!sn-xit-04!supernews.com!xfer13.netnews.com!netnews.com!wn1feed!wn2feed!worldnet.att.net!128.230.129.106!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: Ted Dennison Newsgroups: comp.lang.ada Subject: Re: Generics - Difference between ADA and Modula--3 Date: Wed, 07 Feb 2001 14:52:12 GMT Organization: Deja.com Message-ID: <95rneo$eub$1@nnrp1.deja.com> References: NNTP-Posting-Host: 204.48.27.130 X-Article-Creation-Date: Wed Feb 07 14:52:12 2001 GMT X-Http-User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.7) Gecko/20010109 X-Http-Proxy: 1.0 x55.deja.com:80 (Squid/1.1.22) for client 204.48.27.130 X-MyDeja-Info: XMYDJUIDtedennison Xref: supernews.google.com comp.lang.ada:4926 Date: 2001-02-07T14:52:12+00:00 List-Id: In article , comp.lang.ada@ada.eu.org wrote: > > I would have much preferred a rule that allowed arrays of classwide > > objects, but handled them something like the ways arrays of variant > > records are currently treated. > > Ted, with variant records, you know the maximum size, and this is what > is allocated for arrays of unconstrained variant records. > For tagged types, you do not know the maximum size. At link time you could figure that out since by then all the sizes of all the types in the class are known, but that is perhaps too much work. It'd be nice for the users if it could be done, but I'd think it would require a custom linker for Ada programs. Since a lot of compilers rely on common C linkers, I don't think such a solution would be deemed acceptable by vendors. However, that's for *constained* variant record (sub)types. (Perhaps I'm using the wrong terminology.) What I was talking about was that for an unconstrained variant record type, the declaration of an object must have some kind of initializer specifying the variants being used (and thus the size). Thereafter the variant can't be changed, although the other fields can. That would still not get rid of every instance where pointers are needed, as you'd have to be able to live with an array where you are unable to change the components too drasticly. Right now, variant record types and other "indefinite subtypes" may not be used in arrays. However, let's say for a moment that they could be. Such an array would have to have the following restrictions: o Any objects declared of this array's type would have to have an initializer so that all the array elements would be constrained. o Assignments to elements in the array could not change the variants. If we then extend this hypothetical array rule to tagged types, you can just replace "variants" with "tag" in the above, and things should work out. Now that I type this out though, the argument is starting to look quite familiar. If I remember right, the problem with it is that making array elements take up different physical sizes blows simple array indexing out of the water. You'd have to index into it by walking through the array one element at a time. Since this is the same work as traversing a linked-list, you might as well just use a linked-list for this purpose and be done with it. Clearly better minds than mine have already been over this. If a solution was easy enough that *I* could figure it out, we wouldn't be in this pickle in the first place. :-) -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/