Memory alignment and padding
Given the following structure:
How are the members aligned in memory?
I expected word-aligned memory, so for 32-bit:
and thus sizeof(foo) == 16
However, as seen from this: http://boost.codepad.org/zoiC0K2I
the alignment is as follows:
sizeof(foo) == 12
So how can I change alignment?
What is the default alignment for 32- and 64-bit?
Any other comments greatly appreciated
|
|
How are the members aligned in memory?
I expected word-aligned memory, so for 32-bit:
< char >< pad >< pad >< pad > // 1 byte char, 3 bytes padding < short >< pad >< pad > // 2 byte short, 2 bytes padding < void* > // 4 bytes < int > // 4 bytes |
and thus sizeof(foo) == 16
However, as seen from this: http://boost.codepad.org/zoiC0K2I
the alignment is as follows:
< char >< pad >< short > // 1 byte char, 1 byte padding, 2 bytes short < void* > // 4 bytes < int > // 4 bytes |
sizeof(foo) == 12
So how can I change alignment?
What is the default alignment for 32- and 64-bit?
Any other comments greatly appreciated
I am aware that word-aligned members are faster to access than non-word-aligned members. If I was creating an object which was ubiquitous in a real-time system, I might be concerned with the alignment, favouring access-speed over memory-consumption.
On the other hand, if I was programming for an embedded system where memory is limited, I might favour memory-consumption over access-speed.
Knowing the ins out outs of memory alignment helps me make these decisions.
On the other hand, if I was programming for an embedded system where memory is limited, I might favour memory-consumption over access-speed.
Knowing the ins out outs of memory alignment helps me make these decisions.
Sorry - I think I'm a bit trigger happy...
Can I counter your question with this: Why should I not be concerned with their representation in memory?
Can I counter your question with this: Why should I not be concerned with their representation in memory?
Absolutely. Because the alignment implemented by a given compiler vendor for a given platform may or may not agree with other platforms/compilers. In other words, trying to use this information to your advantage will hurt portability and I suspect maintenance will also become troublesome.
If there is no hard evidence that these things need to be considered, the best bet is to embrace the abstractions that the language supports.
If the intention is to serialize data, consider serializing it more flexibly. Boost.Serialization, for example, can serialize classes portability (in XML by default, I think).
There are vendor-specific constructors to "pack" structures but I don't recommend them. This is the kind of "cleverness" that many modern C++ texts discourage.
If there is no hard evidence that these things need to be considered, the best bet is to embrace the abstractions that the language supports.
If the intention is to serialize data, consider serializing it more flexibly. Boost.Serialization, for example, can serialize classes portability (in XML by default, I think).
There are vendor-specific constructors to "pack" structures but I don't recommend them. This is the kind of "cleverness" that many modern C++ texts discourage.
Fair enough, but in the event that I am developing bespoke software for in-house use, and I know the compiler and architecture I'm developing for, I could pose these questions during my design?
Let's say I was designing an in-house market-data system for an investment bank. Millions of prices are received, so I want my structure which represents a price to be fast to access.
How can I use knowledge of how members are aligned to my advantage to optimise my price structure for a given architecture?
Let's say I was designing an in-house market-data system for an investment bank. Millions of prices are received, so I want my structure which represents a price to be fast to access.
How can I use knowledge of how members are aligned to my advantage to optimise my price structure for a given architecture?
We always know the compiler and platform at inception. The problem is that they evolve over time.
Every C compiler I've seen provides a #prama to control alignment. If you need to guarantee alignment, you should use that mechanism. You cannot determine what an implementation may choose as it's default for a given memory model.
closed account (S6k9GNh0)
Even in a language that allows for cross-platform structure alignment (*cough* D *cough), it still isn't the best way to go.
kbw, have you ever used GCC? If I'm not mistaken, it uses __attribute__ inside of the structure declaration.
kbw, have you ever used GCC? If I'm not mistaken, it uses __attribute__ inside of the structure declaration.
Last edited on
closed account (S6k9GNh0)
Gah, I searched for that :/
Then I guess it can do both and does #pragma to keep compatibility with vc++ (ugh).
Then I guess it can do both and does #pragma to keep compatibility with vc++ (ugh).
| Then I guess it can do both and does #pragma to keep compatibility with vc++ (ugh). |
ugh?
Why are you opposed to efforts to make compilers as uniform and cross-compatible as possible? Isn't that a good thing?
Topic archived. No new replies allowed.