#pragma question
-
#pragma pack(push|pop)From what I remember...the last time I read up on what this pragma does was long time. ;) Anyways...my understanding is that it forces a even byte alignment of structures, it's mebers, etc. I've seen it used often in a structure and like I said...my understanding is that it causes data members to fall on quad byte boundries or whatever...for faster access times... I think it's a CPU quirk that data accessed on an even 4 byte boundry is more efficient on 32 bit processers??? Sp my question is this...assuming I am correct in my above thinking... Would it make a logical difference if I were to remove pragma's like this??? I find them annoying...and despite making code more efficient I'm not sure I think it's worth the harder to read code (I like things easy). If this is the case...one more question: The pragma surrounds structs which are then used in a MFC CArray...to holds potentially 1000's of elements... So does this pragma make sure each of those elements will be accessed on an even byte boundry??? Or I guess...would it atleast make sure the first struct item in array was on an even byte boundry, so the rest that followed??? One more question: :) If a struct was 5 bytes would this pragma actually allocate 8 bytes for a single element, in this case using more memory in the trade off of speed in access times??? so 2 elements would actually consume 16 bytes instead of 10? wasting 3 bytes, but causing each to fall on even byte boundries??? Just curious...hope i'm on the right track here :-O Thanks in advance :) It's frustrating being a genius and living the life of a moron!!! -
#pragma pack(push|pop)From what I remember...the last time I read up on what this pragma does was long time. ;) Anyways...my understanding is that it forces a even byte alignment of structures, it's mebers, etc. I've seen it used often in a structure and like I said...my understanding is that it causes data members to fall on quad byte boundries or whatever...for faster access times... I think it's a CPU quirk that data accessed on an even 4 byte boundry is more efficient on 32 bit processers??? Sp my question is this...assuming I am correct in my above thinking... Would it make a logical difference if I were to remove pragma's like this??? I find them annoying...and despite making code more efficient I'm not sure I think it's worth the harder to read code (I like things easy). If this is the case...one more question: The pragma surrounds structs which are then used in a MFC CArray...to holds potentially 1000's of elements... So does this pragma make sure each of those elements will be accessed on an even byte boundry??? Or I guess...would it atleast make sure the first struct item in array was on an even byte boundry, so the rest that followed??? One more question: :) If a struct was 5 bytes would this pragma actually allocate 8 bytes for a single element, in this case using more memory in the trade off of speed in access times??? so 2 elements would actually consume 16 bytes instead of 10? wasting 3 bytes, but causing each to fall on even byte boundries??? Just curious...hope i'm on the right track here :-O Thanks in advance :) It's frustrating being a genius and living the life of a moron!!!Hi I agree with your concern about unnecessarily optimizing the runtime memory layout of C++ entities, and that byte-alignment in this case should enjoy less limelight than more important issues of software development. However, I've had the need to use the packing pragma - typically in scenarios where I'm overlaying a C++ struct on a data byte array. For example, receiving a packet over the network - it's packed tightly by another program that is not necessarily concerned with extra byte-padding - and overlaying a C++ struct on top of that in order to interpret the elements contained in the data. Another example would be reading byte streams from a file. Unless you're responsible for both consumer and provider of such byte sources, you'll have to be careful that the not-so-obvious extra padding of default byte-alignment doesn't cause problems (getting byte streams and C++ struct members out of sync) - because they are very tricky to find. HTH Martin
-
Hi I agree with your concern about unnecessarily optimizing the runtime memory layout of C++ entities, and that byte-alignment in this case should enjoy less limelight than more important issues of software development. However, I've had the need to use the packing pragma - typically in scenarios where I'm overlaying a C++ struct on a data byte array. For example, receiving a packet over the network - it's packed tightly by another program that is not necessarily concerned with extra byte-padding - and overlaying a C++ struct on top of that in order to interpret the elements contained in the data. Another example would be reading byte streams from a file. Unless you're responsible for both consumer and provider of such byte sources, you'll have to be careful that the not-so-obvious extra padding of default byte-alignment doesn't cause problems (getting byte streams and C++ struct members out of sync) - because they are very tricky to find. HTH Martin
-
#pragma pack(push|pop)From what I remember...the last time I read up on what this pragma does was long time. ;) Anyways...my understanding is that it forces a even byte alignment of structures, it's mebers, etc. I've seen it used often in a structure and like I said...my understanding is that it causes data members to fall on quad byte boundries or whatever...for faster access times... I think it's a CPU quirk that data accessed on an even 4 byte boundry is more efficient on 32 bit processers??? Sp my question is this...assuming I am correct in my above thinking... Would it make a logical difference if I were to remove pragma's like this??? I find them annoying...and despite making code more efficient I'm not sure I think it's worth the harder to read code (I like things easy). If this is the case...one more question: The pragma surrounds structs which are then used in a MFC CArray...to holds potentially 1000's of elements... So does this pragma make sure each of those elements will be accessed on an even byte boundry??? Or I guess...would it atleast make sure the first struct item in array was on an even byte boundry, so the rest that followed??? One more question: :) If a struct was 5 bytes would this pragma actually allocate 8 bytes for a single element, in this case using more memory in the trade off of speed in access times??? so 2 elements would actually consume 16 bytes instead of 10? wasting 3 bytes, but causing each to fall on even byte boundries??? Just curious...hope i'm on the right track here :-O Thanks in advance :) It's frustrating being a genius and living the life of a moron!!!"I think it's a CPU quirk that data accessed on an even 4 byte boundry is more efficient on 32 bit processers???" That's correct and the P4 is really horrendous at it. P3s and AMD processors have an easier time of it. Actually, the default packing of data structures is to the size of the item ie., doubles are aligned to the nearest eight-byte boundary, ints on a four-byte boundary, and shorts on a two-byte boundary. From MSDN : "If you use #pragma pack without an argument, structure members are packed to the value specified by /Zp. The default /Zp packing size is /Zp8." I do a lot of work with communications in various manners and we often use pack(1) insure that the data that we transfer is aligned correctly. If the processor has difficulties with that then we just have to deal with it.
-
Yes that is example when pragma pack's are needed. I need them when I'm reading some structure from disk file. If i would not pack it, variables in the structure would have 'byte gaps' between themselves, and structure would be read incorrectly.
its typically used to 'pack' a structure into a certain byte alignment because otherwise the structure gets padded out automatically and things either use up more memory than necessary OR saving and loading mechanisms (particularly on cross platform code or tool development (e.g. 16 bit machines etc.)) end up reading in the wrong amount of data and so the struct it loads is full of rubbish. However, my experience with #pragma pack is that its the most idiotic compiler directive i have seen. You can specify a struct with size 16 bits (using bit fields of type 'unsigned') specify a #pragma pack directive of 2 bytes (so the size of the struct should be 2 bytes in memory) and yet it fails badly and instead aligns it on a 4 byte boundary ! ! Change the unsigned type to unsigned short and it chucks it on a 2 byte boundary, hooray ! ! My verdict : Its absolute rubbish. "When I left you I was but the learner, now I am the master" - Darth Vader