Memory alignment and padding

[steve lorimer]

Given the following structure:

struct foo
{
    char c;
    short s;
    void* p;
    int i;
};

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

[moorecm]

Why are you concerned with their representation in memory?

[steve lorimer]

Knowledge = power! :)

[steve lorimer]

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.

[steve lorimer]

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?

[moorecm]

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.

[steve lorimer]

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?

[moorecm]

We always know the compiler and platform at inception. The problem is that they evolve over time.

[hamsterman]

just use whatever optimization options your compiler provides.

[kbw]

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.

[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]

http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html#Structure_002dPacking-Pragmas

[S6k9GNh0]

Gah, I searched for that :/

Then I guess it can do both and does #pragma to keep compatibility with vc++ (ugh).

[firedraco]

I thought #pragma was a standard thing used for "compiler specific information"?

[Disch]

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?