--On Tuesday, September 02, 2003 3:32 PM -0400 Douglas Paul Gregor <[EMAIL PROTECTED]> wrote:
On Tue, 2 Sep 2003, Mat Marcus wrote:--On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor <[EMAIL PROTECTED]> wrote: > I suspect they are both '4', but that leaves me even more confused > as to why the alignment of std::pair<double, double> would be 8 > (and how to get a POD type with alignment 8 for ourselves!).
Yes, they are both 4. I suspect that the problem may have to do with some unusual alignment rules on this platform. I believe that the rule is something like: a double at the beginning of a struct forces 8 byte alignment, but a double in the middle does not. That is, given
struct A { double d; int i; };
struct B { int i; double d; };
then: sizeof(A) == 16; sizeof(B) == 12; alignment_of<A>::value == 8; alignment_of<B>::value == 4;
Fun, eh? I can double check the compiler release notes for the exact rule if you like.
- Mat
Are there any other crazy rules like this that you know of? We could just add "struct A" from above to the list of types, or if there is a CodeWarrior-specific extension (e.g., something like "#pragma pack" or "atttribute(aligned...)") we could start using compiler-specific extensions to do this, which wouldn't be a bad thing to do anyway.
Doug
There is a #pragma pack. This is the craziest rule that I know of. Perhaps Howard or Andreas could give a more definitive answer. Following is an excerpt from some release notes for this platform/target:
- Mat
===================================================================== === General Notes for 3.0 ====================================================================== ==
- extended alignment modes, Metrowerks conformed to the "Macintosh C/C++ ABI
Standard Specification Revision 1.3" dated Dec. 5, 1996, and "Inside Mac OS X:
Mac Mach-O Runtime Architecture", version Preliminary dated March 2002. Apple
has now decided that both documents are incorect, and that the defintion of
align=power is what ever MrC and GCC are doing.
The rub here is that acording to this change in behavior doubles in a structure
are not 8 byte aligned unless the user aligns them manual by inserting padding,
or if they happen to be the first element in the structure.
Rather then not support the existing behavior a number of new alignment modes now
exist:
#pragma options align=power_mw
always implements the rule: When in power_mw alignment mode, a special exception
is made when the first embedding element of a struct or any element of a union has
the data type of double -- in this case, the embedding alignment for all (directly
included/top level) double members in the aggregate is 8. By the rules of
computing the embedding alignment for the struct being declared, this will also cause
the embedding alignment of the entire struct or union to be at least 8 as well. The
aggregate table entry for power is 8 for such structs.
#pragma options align=power_gcc
always implements the rules used by gcc/MrC:
- the embedding alignment of the first element in a data structure is equal to
the elements natural alignment
- for subsequent elements with a natural alignment less than 4, the embedding
alignment of each element is equal to its natural alignment
- for subsequent elements that have a natural alignment greater than 4
bytes, the embedding alignment is 4, unless the element is a vector data type
#pragma options align=natural
always implement simple alignment with no special rules based on the type
of the first member of a structure. doubles and long longs are 8 byte aligned.
#pragma options align=power
maps to either power_mw or power_gcc depending on the setting of the option:
#pragma alignment_metrowerks on|off|reset
If struct alignment preferences were set to "PowerPC" alignment_metrowerks defaults on.
If struct alignment preferences were set to "PowerPC MrC/GCC" alignment_metrowerks defaults off.
If struct alignment preferences were set to "PowerPC Natural" alignment_metrowerks defaults off.
When on power==power_mw when off power==power_gcc.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
