jim@ISM780B.UUCP (01/14/85)
>Sigh, > until you give me a subclass mechanism that ensures that the >representation of two data types share a common prefix, I'll rely on this >compiler hack. You already have it: struct { common part; union { distinct part1; distinct part2; ... }; }; The distinct parts can of course be structures. This is the only guaranteed portable way to do this. -- Jim Balter, INTERACTIVE Systems (ima!jim)
ndiamond@watdaisy.UUCP (Norman Diamond) (01/15/85)
> >Sigh, > > until you give me a subclass mechanism that ensures that the > >representation of two data types share a common prefix, I'll rely on this > >compiler hack. > > You already have it: > > struct { > common part; > union { > distinct part1; > distinct part2; > ... > }; > }; > The distinct parts can of course be structures. > This is the only guaranteed portable way to do this. Nope; you're only guaranteed a common portion, which might or might not be a prefix. If some one really needs certain fields mapped to the beginning of a structure, they have to take advantage of knowing how the compiler will map the data. If a person can depend on "part" being at the beginning of that struct, then they can also depend on the ordering in every structure. This is a very hard problem -- assuming that one wants a correct solution. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
kpmartin@watmath.UUCP (Kevin Martin) (01/18/85)
In article <133@ISM780B.UUCP> jim@ISM780B.UUCP writes: >> until you give me a subclass mechanism that ensures that the >>representation of two data types share a common prefix, I'll rely on this >>compiler hack. > >You already have it: > >struct { > common part; > union { > distinct part1; > distinct part2; > ... > }; >}; >-- Jim Balter, INTERACTIVE Systems (ima!jim) Unfortunately, that isn't true. I submitted a somewhat poorly-worded solution which would allow your suggestion. Haven't read any flaming replies yet, but then I don't read my news in order :-) The problem with this: struct { common part; union { distinct part1; distinct part2; ... } /* Insert declarator here */ ; }; is that most current compilers require that the programmer invent a name, and insert it in place of the comment in the above source code. This is a twofold problem: The programmer shouldn't have to invent names merely due to a restriction in the compiler (this is a general principle). And, having invented this extra name, the programmer must use it every time one of the 'distinct' parts is used; this detracts from concepts of data structure hiding, since the programmer must know if the element to be accessed is common or in one of the distinct forms. In fact, two extra funny names are needed if the distinct types are structures, e.g. x.name_of_union.part1.element_of_part1 My argument is effectively that, if 'element_of_part1' is unique within all of 'x', why does one need 'name_of_union.part1.'? In such a case, these extra names shouldn't even be needed in the declaration of the struct type! Kevin Martin, UofW Software Development Group
keesan@bbncca.ARPA (Morris M. Keesan) (01/18/85)
------------------------------------------------------ > > >Sigh, > > > until you give me a subclass mechanism that ensures that the > > >representation of two data types share a common prefix, I'll rely on this > > >compiler hack. > > > > You already have it: > > > > struct { > > common part; > > union { > > distinct part1; > > distinct part2; > > ... > > }; > > }; > > The distinct parts can of course be structures. > > This is the only guaranteed portable way to do this. > > Nope; you're only guaranteed a common portion, which might or might not be > a prefix. If some one really needs certain fields mapped to the beginning > of a structure, they have to take advantage of knowing how the compiler will > map the data. If a person can depend on "part" being at the beginning of > that struct, then they can also depend on the ordering in every structure. > > This is a very hard problem -- assuming that one wants a correct solution. > > -- Norman Diamond Maybe I missed something, and we're talking about some hypothetical language which is not C. From the C Reference Manual, section 8.5 (page 196 of K&R): Within a structure, the objects declared have addresses which increase as their declarations are read left-to-right. Each non-field member of a structure begins on an addressing boundary appropriate to its type; therefore, there may be unnamed holes in a structure. This seems to me to guarantee that the common portion above is a prefix, and also to guarantee the ordering in every structure, although it does not guarantee that actual offsets are portably consistent. Any compiler which does not "map the data" with "part" being at the beginning of the struct is incorrect, or is compiling a different language than C. -- Morris M. Keesan {decvax,linus,ihnp4,wivax,wjh12,ima}!bbncca!keesan keesan @ BBN-UNIX.ARPA