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,ef86287aa487b07a X-Google-Attributes: gid103376,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Pb with use of redefined "=" operator Date: 1998/11/10 Message-ID: #1/1 X-Deja-AN: 410471624 References: <363F62F3.3FF7@club-internet.fr> <3640B520.D7BEEE72@elca-matrix.ch> <3641D551.CCA4379C@elca-matrix.ch> Organization: The Mitre Corp., Bedford, MA. Newsgroups: comp.lang.ada Date: 1998-11-10T00:00:00+00:00 List-Id: In article Robert A Duff writes: > Maybe it's no big deal for your stack example -- maybe the stack needs > 100 words, and the tag field makes it 101. But suppose the abstraction > were "point-in-a-plane" or "complex", where the thing needs two words of > useful data -- in that case, adding a tag field is a huge space > inefficiency. And don't tell me memory is cheap -- it takes time to > initialize it, and it can wreck your caching behavior, which costs time, > and time is *not* cheap. > Yes, the language has a flaw. If the langauge has a flaw, let's be certain that we know what that flaw is. As I see it, the fact that all objects of tagged types must have an explicit tag is a side effect of the rule that all objects of tagged types are aliased 3.10(9). But that rule DOES NOT require that all tagged subcomponents must be aliased. In particular, you could have an array of some tagged type: Running the attached program through gnat produces the expected error messages. (Actually you need to run it twice, once with the object declarations commented out.) The key message is: ttest.ads:31:28: prefix of "access" attribute must be aliased So as far as I can tell, requiring 40 bits for the type Tagged_Object is a (legitimate) implementation restriction for gnat, not a language requirement. Tagged subcomponents of array or record types need not have individual tags, but implementors have not tried to fiercely pack such types. This is probably due to 6.2(4,5,and 10). If you pass an element of Tagged_Array as a parameter, it must be passed by-reference. There is no theoretical problem with always passing the tag as a separate parameter, since assignment to an object or component can never change the tag. But that would require a substantial amount of work--and make all calls with tagged parameters slower. Some Ada compilers have done the equivalent for array parameters, so it is not out of the question. But I would hope that any Ada compiler that supported the capability would require that the (component) tagged type be the subject of a representation pragma. (Separable_Tag maybe?) (If Bob Duff really was worried about the requirement that a tagged complex object must have a one word tag, well yes, that is required, but I refuse to worry about one word of storage.) ------------------------------------------------------------------------ package ttest is type Tagged_Object is tagged record X: Boolean := True; end record; for Tagged_Object'Size use 8; type Small_Object is record X: Boolean := True; end record; type Tagged_Array is array (Integer range 1..1000) of Tagged_Object; pragma Pack(Tagged_Array); for Tagged_Array'Size use 1000; type Small_Array is array (Integer range 1..1000) of Small_Object; pragma Pack(Small_Array); for Small_Array'Size use 1000; type Smaller_Array is array(1..1000) of Boolean; pragma Pack(Smaller_Array); for Smaller_Array'Size use 1000; type Smallest_Array is array(1..32) of Boolean; pragma Pack(Smallest_Array); for Smallest_Array'Size use 32; type Tagged_Access is access all Tagged_Object; TArr: Tagged_Array; TAcc: Tagged_Access := TArr(2)'Access; end ttest; -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...