I couldn't find a decent document that explains how the alignment system works and why some types are more strictly aligned than the others.
-
13Remember that C and C++, while syntactically similar in some parts, are really two different languages with different semantics and rules. So please don't spam tags unrelated to the language you are actually asking about. – Some programmer dude Aug 10 '16 at 13:52
-
3Well, the standard should be pretty informative. – cadaniluk Aug 10 '16 at 13:54
-
for C++, [here](http://eel.is/c++draft/basic.align) is what the standard says about it – Carousel Aug 10 '16 at 13:54
-
I added C tag because it is the language that brought this question to my mind ,and added the C++ tag because i am trying to do all typecastings explicitly. – Dogus Ural Aug 10 '16 at 13:58
-
3As your question mentions _typecasting pointers_, it is a good idea to read about [strict aliacing](http://stackoverflow.com/questions/98650/what-is-the-strict-aliasing-rule). – Revolver_Ocelot Aug 10 '16 at 14:12
-
ESR wrote [a good guide about alignment and structure packing](http://www.catb.org/esr/structure-packing/) that will be of interest. – Rob K Aug 10 '16 at 14:24
-
6It is just amazing how such a question (no code, no demonstrated research effort, kinda broad) can have this score... – Eugene Sh. Aug 10 '16 at 14:30
-
1You may have a look at [this article](http://www.catb.org/esr/structure-packing/) which explains in details how alignment works. – shrike Aug 10 '16 at 15:12
-
I am afraid I have to vote to close this. It is already very broad and asking about two different languages with extremely different rules and good practices in one question sends this way over the edge of not being answerable well in the format of this site. – Vality Aug 10 '16 at 17:32
-
How is this not a duplicate 8 years after Stack Overflow was launched (and more than 12,000,000 questions)? – Peter Mortensen Aug 10 '16 at 19:09
3 Answers
I'll try to explain in short.
What is data alignment?
The architecture in you computer is composed of processor and memory. Memory is organized in cells, so:
0x00 | data |
0x01 | ... |
0x02 | ... |
Each memory cell has a specified size, amount of bits it can store. This is architecture dependent.
When you define a variable in your C/C++ program, one or more different cells are occupied by your program.
For example
int variable = 12;
Suppose each cell contains 32 bits and the int
type size is 32 bits, then in somewhere in your memory:
variable: | 0 0 0 c | // c is hexadecimal of 12.
When your CPU has to operate on that variable it needs to bring it inside its register. A CPU can take in "1 clock" a small amount of bit from the memory, that size is usually called WORD. This dimension is architecture dependent as well.
Now suppose you have a variable which is stored, because of some offset, in two cells.
For example I have two different pieces data to store (I'm going to use a "string representation to make more clear"):
data1: "ab"
data2: "cdef"
So the memory will be composed in that way (2 different cells):
|a b c d| |e f 0 0|
That is, data1
occupies just half of the cell, so data2
occupies the remaining part and a part of a second cell.
Now suppose you CPU wants to read data2
. The CPU needs 2 clocks in order to access the data, because within one clock it reads the first cell and within the other clock it reads the remaining part in the second cell.
If we align data2
in accordance with this memory-example, we can
introduce a sort of padding and shift data2
all in the second cell.
|a b 0 0| |c d e f|
---
padding
In that way the CPU will lose only "1 clock" in order to access to data2
.
What an align system does
An align system just introduces that padding in order to align the data with the memory of the system, in accordance with the architecture.
Why should I care about alignment?
I will not go deep in this answer. However, broadly speaking, memory alignment comes from the requirements of the context.
In the example above, having padding (so the data is memory-aligned) can save CPU cycles in order to retrieve the data. This might have an impact on the execution performance of the program because of minor number of memory access.
However, beyond the above example (made only for sake of the explanation), there are many other scenarios where memory alignment is useful or even needed.
For example, some architectures might have strict requirements how the memory can be accessed. In such cases, the padding helps to allocate memory fulfilling the platform constraints.

- 9,368
- 2
- 26
- 50
-
8`This is done for performance reasons (99% of times).` IMO should immediately be followed by the disclaimer that 99% of statistics are fabricated on the spot, then a precise explanation of the possible reasons that account for the other '1%'. Like unaligned accesses causing trap representations, hardware exceptions, etc. Saying this is mostly about speed without explaining other, often more important reasons is barely any better than saying it's entirely about speed, which would be false. – underscore_d Aug 10 '16 at 20:30
-
1@underscore_d *"Saying this is mostly about speed [...] is barely any better than saying it's entirely about speed"* for someone unfamiliar to the concept of memory alignment like me, it's a good thing to know it's not only for efficiency, because that's what I thought it was all about just 2 minutes ago. I wouldn't call it "barely any better", as it still consists in relatively accurate information. Even thought I believe your point is fair (also, thanks for naming some of the "1%" cases), it just feels like you're trying to discredit an otherwise great answer. – ljleb Jan 26 '22 at 00:51
-
-
@Ijleb: Well... it's done for performance reasons *on x86_64*, because that architecture happens to be pretty relaxed about alignment ("just" being slower on most misaligned accesses). Various other platforms will run into CPU trips (hardware exceptions) on misaligned access. So, if someone takes this answer as "oh, it's just performance, I can safely ignore that", they've gotten the wrong message. – DevSolar Feb 09 '22 at 15:07
-
I think they are right. The sentence "`This is done for performance reasons (99% of times).`" is admittedly a little flawed. I am going to edit the answer. – BiagioF Mar 03 '22 at 20:46
This is "implementation defined", i.e. the alignment requirements are not part of the language specification.
Different CPUs have different requirements on alignment. Some could not address a 16bit value on an uneven address, some could. Some could not address a floating point value unless aligned to an address divisible by its size, some could. And so on. Some would access misaligned data objects more slowly than properly aligned ones, others would trip over an unaligned access.
That is why the language standard does not go into the details of which type needs to be aligned which way (because it couldn't), but left it to the "implementation" -- the compiler backend, in this case.
If you typecast pointers, you might be forcing the code to address a given object at an address where it cannot be addressed. You need to ensure that the alignment requirements of the "old" type are at least as strict as those of the "new" type.
In C++ (C++11 upwards), you get the alignof operator to tell you the alignment requirements of a given type. You also get the alignas operator to enforce a more strict alignment on a given type or object.
In C (C11 upwards), you get the _Alignof and _Alignas operators, which <stdalign.h>
wraps into the alignof
/ alignas
convenience macros. (Thanks, Lundin -- C11 is not my forte.)

- 67,862
- 21
- 134
- 209
-
4
-
2This is a superior answer for mentioning that alignment rules depending on architecture exist for either speed or necessity - mentioning both - whereas each of the other answers focuses only on one of the two, to such an extent that they downplay the other factor's importance almost to nil. – underscore_d Aug 10 '16 at 20:34
Some systems can access memory in portions of, say, 32-bit words (4 bytes). It's a hardware limitation. It means that the actual address going into the memory controller should be divisible by four (as it is still addressing the bytes). So once you try to have a word located at address which is not divisible by four, there ate two options - either the compiler will try to generate some fancy code to compose the word out of two memory accesses, but it is not always the case. Sometimes it will just generate a code to access 4 bytes out of the given address. And then the processor will fail with the data alignment error.
Which leads to limitation the language is imposing.
Consider the code (a bad one):
uint8_t a[] = {1,2,3,4,5,6};
uint32_t b = *(uint32_t*)&a[1];
and assume a
is aligned to the divisible by four boundary.
Then the second line is trying to read a word out of an address of it's second element, i.e. an address not divisible by four. It will lead to the alignment error. But in C
it is simply forbidden by the strict aliasing rule.

- 17,802
- 8
- 40
- 61
-
1The gcc compiler has a `-Wcast-align` option to specificly warn against such errors. – hlovdal Aug 10 '16 at 15:53
-
1`either the compiler will try to generate some fancy code to compose the word out of two memory accesses, but usually it is not the case.` Please define "usually". x86 can handle unaligned accesses just fine for basic load/store instructions by aggregating reads/writes, [e.g. link](http://stackoverflow.com/questions/12491578/whats-the-actual-effect-of-successful-unaligned-accesses-on-x86). And isn't x86 our usual reference point for terms like "usual"? What architectures were you talking about instead? – underscore_d Aug 10 '16 at 20:37
-
2@underscore_d I will replace "usually" by "it is not always the case". I am used to ARMs and lower-end MCUs, so they are usual to me. – Eugene Sh. Aug 10 '16 at 20:45