Re: alignment problem / gcc compatibility

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

"Mycroft Holmes" <m.holmes@xxxxxxxxx> wrote in message
news:%23DwO4ArRGHA.2156@xxxxxxxxxxxxxxxxxxxx
John Carson wrote:

I am not an expert in offsetof (which represents a type of low level
coding that I prefer to avoid), but I don't agree that

offsetof(x, d) >= __alignof(double)

If you use the /Zp4 switch, then offsetof(x, d) equals 4, whereas
__alignof(double) equals 8.

From my understanding, offsetof(x,d) should give you exactly how far
from the start of x the variable d is. Since sizeof(x) must be >=
this value + sizeof(double), the first inequality I gave must be
satisfied and hence the code is legal.


correct, but the point is: by definition, A is the alignment of type T
if it's the smallest positive integer such that EVERY object of type T
must be constructed at an address which is a multiple of A.
"every" includes class data members, so if x::d is a double, I'd
expect it to be aligned as any other double, but if offsetof(x, d) ==
4, then in an array of x of length 2, at least one double will be
misaligned: declare

x a[2];

if a's address is, say, 8N, then a[0].d lies at 8N+4; if a is 8N+4,
then a[1].d lies at (8N+4)+12+4...

The whole point of the packing settings is that you can make types appear at
other than their natural alignment. If you use the /Zp1 switch and declare

struct y
{
double d1;
char c;
double d2;
};

then sizeof(y) is 17 and one double will be at an odd-numbered address.

This is safe but harms performance.

The only time that alignment settings can get you into trouble is when you
use third-party libraries, including Windows dlls. You must #include the
third party header with the same packing values as was used in the
compilation of the third party library, otherwise disaster ensues. In the
case of Windows, #pragmas internal to the header generally ensure this,
though there has been at least one notorious case where the #pragma was
missing. I don't know if the problem has been fixed, but the advice used to
be that if you are using a packing less than 4, then you should use:

#pragma pack(push, 4)
#include <windows.h>
#pragma pack(pop)


--
John Carson



.

Relevant Pages

  • Re: padding mechanism in structures
    ... #pragma pack([n]) ... Specifies packing alignment for structure and union members. ... level by the pack pragma. ...
    (comp.lang.c)
  • Re: reading a C++ structure from a binary file using C#
    ... because it pragma pack was used several different values would be possible. ... The int is the first field of the struct, the second is a char array which has no alignment restriction, so, whatever the packing, the length written on disk will be 74. ... Padding is included in sizeof, because sizeof is the separation between adjacent array elements which must both be properly aligned. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Packing for __nogc classes
    ... not the library author's for failing to use a #pragma ... Windows.h, and all windows related header files, as well ... >packing through /Zp. ... Which is why I mentioned them in my first message to you. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Data alignment problems with sizeof and new
    ... It turned out to be a #pragma packwhich didn't ... restore the packing to normal. ... >>operators are not taking the alignment padding into account when calculating ... >>class with the first member being a dword size followed by doubles, ...
    (microsoft.public.vc.language)
  • change a #include directory
    ... I trying to get the preprocessor to include a file from a directory based on ... I want to be able to switch between internal ... #ifdef USE_TRUNK ... (I also want to use a #pragma comment lib to link ...
    (microsoft.public.vc.language)