Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!ucsd!pacbell.com!pacbell!indetech!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.std.c++ Subject: Re: Controlling structure layout (Re: Randomly ordered fields !?!?) Message-ID: <1990Sep14.051702.19333@zorch.SF-Bay.ORG> Date: 14 Sep 90 05:17:02 GMT References: <57316@microsoft.UUCP> <1990Sep12.083730.28345@zorch.SF-Bay.ORG> <57425@microsoft.UUCP> Organization: SF Bay Public-Access Unix Lines: 33 bobatk@microsoft.UUCP (Bob ATKINSON) writes: >Kent Paul Dolan writes: > >>If the goal is to share structures in a shared memory >>architecture, between two vendor's compilers, or two generations >>of one vendor's compilers, then none of the questions of >>endedness, bit ordering, efficient bit path width for fetches and >>stores will vary, nor need they be considered when laying out a >>standard for structure packing. Those problems exist >>_independently_ of any compiler, they are at the hardware level, > >My understanding was, for instance, that it would be quite resonable >for one C or C++ compiler to implement signed bit fields, and another, >unsigned bitfields. A similar situation applies to the grouping >chunk size of bit fields. A choice of processor may suggest >certain sizes, but it by no means pins these things down precisely. >Jim correctly identifies these as compiler issues, not hardware >ones. I realize I'm being incredibly obtuse here, but "huh"? If I want to pack, from a particular four four-bit fields A,B,C,D, and eight two-bit fields p,q,r,s,t,u,v,w, in order A,p,B,q,C in the first two byte int, and r,s,t,D,u,v,w in the second two byte int, for my own malicious reasons, what does it matter whether the bit fields are signed or not, for heavens sake? Help me out here. I see lots of complications being introduced in the name of not solving this problem that don't seem to have anything to do with it. What am I missing? Kent, the man from xanth.