preprocessor directive

Started by
5 comments, last by Zahlman 17 years, 7 months ago
Hello all, can somenone explain to me the mean of preprocessor directive: #pragma pack( pop, 1 ) and general the mean of pack?? Moreover can you tell me what the headers pshpack1.h and poppack.h helps for? thanx a lot :)
Advertisement
#pragma pack effects the alignment of members in classes/structs/etc.
#pragma pack(pop, 1) usualy follows a #pragma pack(push, 1), and returns the alignment setting to whatever it was prior to being set to 1

More info here.
Yes, but what packing alignment means?
If you have something like:

class blah { char a; int b; }

You'll find it takes up 8 bytes, as there is 'padding' between the char and the int, to make sure that the int starts on an int-sized boundary. The members are 'aligned' to these boundaries.

Set the packing to 1 and recompile, and the structure will be 5 bytes - smaller, but probably running more slowly because of the unaligned variable.
whats the difference between #pragma pack( push, 1 ) and __declspec( align(16) ) ? I understand how #pragma pack( push, 1 ) changes the alignment, but what exactly does the __declspec do? According to MSDN this is what is says
Quote:Use __declspec(align(#)) to precisely control the alignment of user-defined data (for example, static allocations or automatic data in a function).


So is it stating that you are forcing all variables to be X bits in size (ie. __declspec( align(16) ) forces all variables to be 16 bits in size, so an int would really be 2 16bit words?)

While these are both probably only optimization uses, are they necessary in most builds, or is the compiler able to be speedy enough without them?

tHom.
Packing affects how data is aligned within a structure or class, ie. where it starts with relation to the beginning of the structure. Alignment affects how data is aligned in memory, ie. where it starts with relation to memory as a whole.

In your second link, follow the 'for more information on alignment' link - everything you need to know is there.

They're almost completely unnecessary for use in 99.5% of the software you compile.
Quote:Original post by Kylotan
They're almost completely unnecessary for use in 99.5% of the software you compile.


Quoted for extreme emphasis.

The rule of thumb is that if you can't figure out on your own (plus [google]) what a language construct is for, you don't need to worry about what it does. The time to figure out new language constructs is when the ones you currently understand don't seem adequate for the problem you're trying to solve (or using them seems unwieldy).

This topic is closed to new replies.

Advertisement