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. 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. 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? There are some type safety constraints on that, but the right mechanism would be repr, not anonymous union. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
