#pragma pack
-
hi , what is the meaning of #pragma pack ? From MSDN I came to know that it specifies the packing alignment for structure and union members . But what is meant by packing alignment ? Can you please tell me. Thanks in advance
If you declare a struct with char dummy; short x; long y; members, the "optimal" size would be 1 + 2 + 4 (assume x86 for the moment). However, this would be with alignment of 1. This says what byte boundary you use for packing. With an alignment of 2, each member begins on the next available 2 byte boundary, so the single char would be followed by an unnamed pad byte, the short would already be aligned correctly, as would the long. Similarly with 4 byte, the char is followed by 3 unnamed pad bytes, the short by another two, and the long would be OK as is. I can almost hear you asking "Why would I want to waste memory like that?" [fx: pause for reader to actually ask...] It's all to do with the way the processor accesses memory, and for some CPUs, like the SPARC, trying to access a packed (1) long would cause an exception. The important thing is to consistently use the same alignment for all in memory versions of a structure. For instance, if you build a DLL with a function that takes a structure, the declaration of that structure should really include #pragma pack(push) #pragma pack(n) struct { .... }; #pragma pack(pop) so that irrespective of the compile time options elsewhere, it has the packing n (where n is a power of 2). Without this, you might build the DLL with pack(2), for instance, and a client might be built with pack(1). This would misalign the data, and might even result in an access violation when you call the DLL function. Does that help? Steve S Developer for hire
-
If you declare a struct with char dummy; short x; long y; members, the "optimal" size would be 1 + 2 + 4 (assume x86 for the moment). However, this would be with alignment of 1. This says what byte boundary you use for packing. With an alignment of 2, each member begins on the next available 2 byte boundary, so the single char would be followed by an unnamed pad byte, the short would already be aligned correctly, as would the long. Similarly with 4 byte, the char is followed by 3 unnamed pad bytes, the short by another two, and the long would be OK as is. I can almost hear you asking "Why would I want to waste memory like that?" [fx: pause for reader to actually ask...] It's all to do with the way the processor accesses memory, and for some CPUs, like the SPARC, trying to access a packed (1) long would cause an exception. The important thing is to consistently use the same alignment for all in memory versions of a structure. For instance, if you build a DLL with a function that takes a structure, the declaration of that structure should really include #pragma pack(push) #pragma pack(n) struct { .... }; #pragma pack(pop) so that irrespective of the compile time options elsewhere, it has the packing n (where n is a power of 2). Without this, you might build the DLL with pack(2), for instance, and a client might be built with pack(1). This would misalign the data, and might even result in an access violation when you call the DLL function. Does that help? Steve S Developer for hire