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,72340e997bfd5289 X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: array size Date: 1999/12/13 Message-ID: #1/1 X-Deja-AN: 560128866 Sender: bobduff@world.std.com (Robert A Duff) References: <101219991605504828%hopperj@macconnect.com> <3851d15b_1@news1.prserv.net> <82to3s$ng7$1@nnrp1.deja.com> <3852887a_4@news1.prserv.net> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-12-13T00:00:00+00:00 List-Id: "Matthew Heaney" writes: > RM83 4.9 was too conservative wrt what's officially static, and RM95 4.9 > improved things, but RM95 4.9 is still too conservative. There's no > obvious reason I have to use the locution above (always declare a static > constant for composite type sizes, and refer to the constant instead of > T'Size). What's "incomprehensible" is the rationale for not allowing > some composite types to be officially static. It does seem odd. However, I think there are some reasons for it. For one thing, it simplifies the description of the rules. Clearly T'Size can be static if T is a dynamic array, or a a record containing discriminant-dependent arrays. Also, T'Size can't be static if any of the component types are private, or partly private. Writing down exactly when T'Size can be static for records would be a pain. Another thing is that T'Size for records is highly machine dependent -- it depends on alignment considerations, for example. Therefore, you would like to determine T'Size in the back end of the compiler. But static expressions have to be evaluated in the front end of the compiler, because they affect overload resolution (of weird things like A'First(T'Size)), and they affect various legality rules. For scalar types, on the other hand, 'Size is not quite so hardware dependent. Especially with the Ada 95 rules, where, for example, the Size of an integer type is pretty much determined by its range. (Well, *almost*. Allowing *any* 'Size to be static seems annoying to me, as a compiler writer.) So, implementing Scalar'Size in the front end isn't so horrible, whereas implementing Record_Type'Size in the front end would damage the structure of compilers. Or are you suggesting that T'Size should be legal for records and arrays if and only if T'Size was specified in a rep clause? That could work, but it also seems a little odd to me. I believe that in an early version of Ada 9X, there were two kinds of static expressions, in order to solve the above problem. Record'Size could be static in the sense that it affects generated code in a compile-time-known way, but not in the legality-affecting or (shudder) overload-resolution-affecting way. I think this was rejected as being overly complicated. - Bob