On Fri, May 16, 2014 at 5:59 AM, Jonathan S. Shapiro <[email protected]> wrote: > On Fri, May 16, 2014 at 3:40 AM, Matt Rice <[email protected]> wrote: >> >> On Tue, May 13, 2014 at 6:37 AM, Jonathan S. Shapiro <[email protected]> >> wrote: > > >> >> > Can anybody give a serious use case where it would be advantageous >> >> > to specify two different bit-level representations for a type without >> > changing >> >> > the type itself? I am not aware of any. >> >> The only cases i can think of is that a logical ordering of a structure >> in the sources may not emit an efficient aligning of fields, and one may >> prefer >> to keep the logical ordering in the structure declaration, or discover >> this later and be faced with issues of separate compilation. > > > That's the case we all know about: co-declaring the representation with the > structure type. My question concerned cases where perhaps we would want the > same structure type to have two different shapes in two different places. > > The only case I've been able to identify that comes even close arises in > networking, where you can be forced to marshall to non-native byte order > (and consequently to non-native bit order). But that's a very unusual case, > and the key word there is "marshall". It's something that occurs during I/O.
Right, in general of the cases I came up with in this category one could easily imagine requiring some form of transformation being required, such that it didn't seem universally useful. > As you note, you can't really retrofit a shape after the fact. This is true > because the shape is part of the byte-level compatibility requirements for > the type. right, the thought was that the ability to cast the structure between repr's for calling in to separately compiled code using an older ABI introduces a 2nd repr. >> something which I have not thought about nearly enough to know if it >> can be done safely is unionizing mutually exclusive fields which have >> been discovered to be mutually exclusive, for which a bunch of source >> code currently exists. Though i'm guessing though this probably would >> be done via the changing the type to some form of anonymous union, so >> that the old code still compiles > > > You mean noticing that two fields are never used at the same time, and so > can share space? yeah > There are some type safety constraints on that, but the right mechanism > would be repr, not anonymous union. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
