On 5/23/08 6:19 AM, Roland Schwarz wrote:
The proposed lib actually does have an unaligned type, i.e. it actually maps the types to char bytes[..] arrays. So the question remains what the standard has to say about alignment of
struct foo { char bytes_1 [3]; char bytes_2 [2]; char bytes_3 [1]; char bytes_4 [4]; };
Will such a struct be equivalent to char bytes[3+2+1+4] ?
I am not a language lawyer, but my understanding is that struct members will be aligned according to their needs, and a type that contains only chars will need no special alignment. The endian library therefore takes care of alignment down to the byte level.
1) I wanted a way to control layout on a per struct basis. I wanted to be able to go as low as bit position.
I think it is very unlikely that a portable library would be able to get control over bit positions. At least, not in a purely data-declarative way. However, you could use a boost endian type as the underlying storage and add methods to access bit ranges within that. For example, the addition of a general bit-range access method to the endian template would help here, one which takes a bit offset and a length, and you would then add access methods to the combined struct that call the bit-range one on individual endian fields.
Hmm, and foo isn't necessarily a POD. Writing this out with binary write... what is guaranteed? I fear not much.
Provided the alignment and length of endian fields is guaranteed (which I believe it is) then the only other thing that could get in the way is "hidden" content in the combined struct. However, provided there are no virtual methods, what you see is what you get. So I think binary read/write will always work, and it seems to me that this is the main point of endian. I'm not sure what the standard says, but it would work with any of the compilers I have used in the past 10 years or so. --Neil