<p>I am bothered by the fact that, in C, <code>struct</code> types can be arbitrarily large. We have no control over their memory layout except for the fact that the first member is always at the beginning of the memory and the elements are arranged in the order we defined them in. A <em>'conforming'</em> but never to be seen in practice C implementation may handle a <code>struct</code> as follows:</p>
<pre><code>struct S {
    char x; // 1 byte
    // 999999999 bytes padding
    char y; // 1 byte
    // 999999999 bytes padding
    short z; // 2 bytes
    // 999999998 bytes padding
}; // Total size: 3 GB
</code></pre>
<p>To solve such problems, I am considering implementing a <code>packed</code> keyword to my programming language. <code>packed struct</code> would require using the least amount of space with no padding, and that all elements immediately follow each other. <code>packed enum</code> would use the smallest type that can hold all enumerators instead of some default type such as <code>int</code>.</p>
<p>What are the implications to implementing such a feature? Are there reasons, performance, compatibility, or otherwise, to refrain?</p>

<data-structures><struct-packing>
What are the implications of a 'packed' keyword/feature?
CC BY-SA 4.0
2024-03-27T20:03:32.710Z
Implicit in any useful programming language is that any implementation will do its best to be as efficient as it can be.  So padding will only be introduced if it makes things more efficient, and such silly paddings like you describe, while technically "legal" according to the spec, will not happen.
Chris Dodd
<p>More useful than a <code>packed</code> keyword would be a more <em>general</em> means of specifying that a blob of memory should be treated as a structure with a precisely-specified layout which might be relied upon by outside code.  Code which repeatedly assesses data items within such a structure would generally be slower than code which converts a structure's contents to an implementation's &quot;native&quot; numeric formats, manipulates them, and converts them back, but if it's only necessary to manipulate a small portion of the data structure, the overhead of performing such manipulation &quot;in place&quot; may be less than the cost of performing a round-trip conversion on the entire structure.  Note that even if a field uses a format inconsistent with a platform's normal numeric formatting (e.g. a big-endian field on a little-endian platform), it would be easier for an implementation given e.g. <code>thingie.woozle++;</code>, where <code>woozle</code> is a 32-bit big-endian value at offset 38 of a word-aligned structure, to generate efficient machine code to handle that task than to generate equally-good machine code for all of the ways programmers might try to accomplish that task without such a language feature.</p>
<p>Although situations in which the space savings of using a packed data structure would be relevant are rare, situations where it would be useful to treat a blob of data <em>which is formatted to fit the needs of some outside code</em> using the same syntax as native-format data are much more common, and a language which is intended to facilitate the writing of portable programs should include features to work with octet-based data in precisely-specified formats.  Note that such features would be especially useful on implementations that don't use octet-based storage, since it would allow non-octet-based platforms to exchange information with octet-based systems using information-interchange code written for octet-based platforms.</p>

CC BY-SA 4.0
2023-12-14T22:44:57.800Z
2023-12-14T22:44:57.800Z
supercat
CC BY-SA 4.0
2023-12-15T01:56:45.670Z
This approach can be seen for example in Python, using tools such as the `struct` standard library module to `unpack` data from a `bytes` source and `pack` it back in.
Karl Knechtel
CC BY-SA 4.0
2023-12-15T17:35:05.977Z
I think Ada has a feature like this.
Pablo H
<p>For precedent, Microsoft's compiler <a href="https://learn.microsoft.com/en-us/cpp/preprocessor/pack" rel="nofollow noreferrer">has a pragma</a> for that: <code>#pragma pack()</code>:</p>
<blockquote>
<p>To pack a class is to place its members directly after each other in memory. It can mean that some or all members can be aligned on a boundary smaller than the default alignment of the target architecture.
[...]
If you change the alignment of a structure, it may not use as much space in memory. However, you may see a loss of performance or even get a hardware-generated exception for unaligned access.</p>
</blockquote>
<p>Also, R. Chen wrote <a href="https://devblogs.microsoft.com/oldnewthing/20200103-00/?p=103290" rel="nofollow noreferrer">a page about #pragma pack</a>, packed with good insight and examples of generated code (pun forced). For example:</p>
<blockquote>
<p>Changing the default structure packing has another consequence: It changes the alignment of the structure itself. In this case, the #pragma pack(1) declares that the structure P can itself be placed at any byte boundary, instead of requiring it to be placed on a 4-byte boundary.</p>
</blockquote>
<p><a href="https://www.ibm.com/docs/en/zos/3.1.0?topic=descriptions-pragma-pack" rel="nofollow noreferrer">Some</a> <a href="https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Structure-Layout-Pragmas.html" rel="nofollow noreferrer">other</a> <a href="https://releases.llvm.org/3.4/tools/clang/docs/UsersManual.html" rel="nofollow noreferrer">compilers</a> also have or had similar pragmas. GCC also has <a href="https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Type-Attributes.html" rel="nofollow noreferrer"><code> __attribute__ ((__packed__))</code></a>.</p>

CC BY-SA 4.0
2023-12-14T00:39:23.403Z
2023-12-14T15:57:27.170Z
2023-12-14T15:57:27.170Z
Pablo H
<h3>Padding and Packing</h3>
<p>The layout of structures is defined by the ABI (Application Binary Interface). The typical mindset of an ABI designer is mechanical sympathy, with an eye towards performance (speed).</p>
<p>To talk about padding, we need to talk about alignment, size, and <em>stride</em>.</p>
<p>First is alignment. Native types tend to have an alignment, that is the <em>architecture</em> expects that a <code>double</code> is either 4 or 8 bytes aligned (depending). This alignment then bleeds into compound types: the only way to ensure that a <code>double</code> field is 8 bytes aligned is for the compound type containing the field to itself by 8 bytes aligned, hence a compound type's alignment is the greater alignment of any of its components.</p>
<p>Second is size. Native types have a size, too. For example a <code>double</code> is typically 8 bytes. The size of the compound type will depend on the size and alignment of its components, as per the ABI rules.</p>
<p>Finally is stride. The stride of a type is the spacing between consecutive array elements. Swift is one of the few languages differentiating size and stride, in C the stride is always the size.</p>
<p>With that in mind, here is a typical product type ABI, as can generally be found in C:</p>
<ul>
<li>The alignment of the product type is the maximum alignment of any of its fields.</li>
<li>The first field starts at the first byte of its product type.</li>
<li>Any subsequent field starts at the next offset which guarantees its alignment, which may lead to &quot;in-between&quot; padding bytes.</li>
<li>The size of the struct is rounded-up to a multiple of its alignment, which may lead to &quot;tail&quot; padding bytes.</li>
</ul>
<p>And since a picture is clearer than words:</p>
<pre class="lang-c prettyprint-override"><code>struct ProductType {
    int i;
    char __padding_0[P0];
    double d;
    char __padding_1[P1];
    char c;
    char __padding_2[P2];
};
</code></pre>
<p>On x64, we have:</p>
<ul>
<li><code>int</code>: 4 bytes, 4-bytes aligned.</li>
<li><code>double</code>: 8 bytes, 8-bytes aligned.</li>
<li><code>char</code>: 1 byte, 1-byte aligned.</li>
</ul>
<p>Therefore:</p>
<ul>
<li>P0 = 4. This is because <code>d</code> must start at an offset that is a multiple of 8, and after <code>i</code> the offset is only 4.</li>
<li>P1 = 0. This is because <code>c</code> must start at an offset that is a multiple of 1, and any offset is.</li>
<li>P2 = 7. This is because the alignment of <code>ProductType</code> is 8, hence its size must be a multiple of 8.</li>
</ul>
<p>Note that Swift would have P2 = 0.</p>
<p>The effect of packing is, very simply, to remove all padding.<sup>1</sup></p>
<p><sup>1</sup> <em>I am aware that some compilers take the opportunity to also allow specifying the struct alignment when packing. That's a potentially useful extra feature, but it's not packing.</em></p>
<h3>Implications of Packing</h3>
<p>The first and foremost implication is that you should implement it properly, or users will curse you.</p>
<p>For example, it seems reasonable to allow taking a reference (or pointer) to a field of a packed struct. However, this reference (or pointer) may now be under-aligned: that is, its alignment may be strictly less than the expected alignment of a pointer of this type.</p>
<p>Different languages &amp; toolchains handle the situation differently:</p>
<ul>
<li>In Zig, pointer alignment is a part of the pointer type, so a compilation error will follow if one attempts to use an under-aligned pointer where a regular pointer is expected.</li>
<li>In GCC (C or C++), the compiler handles under-aligned pointers properly within the function in which the pointer was created, but allows passing the under-aligned pointers to functions expecting a regular pointer... which leads to Undefined Behavior.</li>
<li>In Rust, manipulating packed fields is <code>unsafe</code>, and the user is on the hook to tread carefully, or they will trigger Undefined Behavior.</li>
</ul>
<p>I would argue that the situation of being able to create an under-aligned pointer, but then have to walk on eggshells forever, is not desirable from a user point of view, and thus that language designers going the <code>packed</code> way should either disallow forming such pointers, or follow through and ensure they provide users the tooling they need to manipulate under-aligned pointers.</p>
<h3>Alternatives</h3>
<p>There are alternatives to packing, for the memory conscious.</p>
<p>As mentioned, packing is about avoiding padding, and there are two sources of padding:</p>
<ul>
<li>In-between fields padding.</li>
<li>Tail padding.</li>
</ul>
<p>Tail padding is eliminated in a language such as Swift which differentiates size &amp; stride.</p>
<p>In-between fields padding is eliminated in a language such as Rust which reserves the right to re-order fields arbitrarily -- and typically will reorder them by descending alignment, which removes all in-between fields padding.</p>
<p>Those two alternatives, combined, remove nearly<sup>2</sup> any and all padding in a <code>struct</code><sup>3</sup> without introducing under-aligned references and pointers into the fray.</p>
<p>I would typically advise considering them <em>first</em>:</p>
<ul>
<li>Provide the same memory gains as packed, without taxing the user.</li>
<li>Without performance penalty incurred from under-aligned pointers.</li>
<li>Without headaches induced by under-aligned pointers.</li>
</ul>
<p>You may still want to later introduce under-aligned pointers in the language, <em>separately</em>.</p>
<p><sup>2</sup> <em>Unless reordering can interleave the fields from different field structs, there may still be some padding in between structs. For example, a struct A (int, char) followed by itself would still have 3 bytes of padding between the two instances, no matter the order.</em></p>
<p><sup>3</sup> <em>Padding may still occur between array elements, the exact amount of padding inserted being equal to <code>stride - size</code>.</em></p>

CC BY-SA 4.0
2023-12-14T15:24:29.410Z
2023-12-15T08:16:38.740Z
2023-12-15T08:16:38.740Z
Matthieu M.
<p>According to <a href="https://www.catb.org/esr/structure-packing/" rel="noreferrer">“The Lost Art of Structure Packing” by Eric S. Raymond</a>, structure packing can slow down your program or worse:</p>
<blockquote>
<p>The first thing to understand is that, on modern processors, the way your compiler lays out basic datatypes in memory is constrained in order to make memory accesses faster. Our examples are in C, but any compiled language generates code under the same constraints.</p>
<p>…</p>
<p>Self-alignment [that is, aligning to an address divisible by the size of the datatype] makes access faster because it facilitates generating single-instruction fetches and puts of the typed data. Without alignment constraints, on the other hand, the code might end up having to do two or more accesses spanning machine-word boundaries.</p>
<p>…</p>
<p>I said “on modern processors” because on some older ones forcing your C program to violate alignment rules (say, by casting an odd address into an int pointer and trying to use it) didn’t just slow your code down, it caused an illegal instruction fault.</p>
</blockquote>
<p>On the other hand, structure packing is useful “if you intend to write code for memory-constrained embedded systems, or operating-system kernels. It is useful if you are working with application data sets so large that your programs routinely hit memory limits. It is good to know in any application where you really, really care about optimizing your use of memory bandwidth and minimizing cache-line misses.” Raymond goes on to describe a program of his that kept getting OOM errors, for which he managed “to cut the working-set size by around 40%” by carefully arranging his structures.</p>

CC BY-SA 4.0
2023-05-22T05:07:24.343Z
2023-05-22T05:21:02.260Z
2023-05-22T05:21:02.260Z
Brandon Dyck
<p>Generally, compilers optimise for program speed rather than memory use. This is because in typical desktop and laptop PCs, memory is abundant, and a suboptimal struct layout won't waste that much memory; even a naive compiler should not make a struct take up more than twice as much space as necessary. On the other hand, optimising the execution speed of the program can easily yield improvements by much greater factors than two.</p>
<hr />
<p>Another issue is that modern compilers are often better able to know whether an optimisation is worth applying, than the human writing the code. When languages allow the programmer to provide optimisation hints, like an <code>inline</code> keyword for functions, these are typically just treated as hints and the compiler will gladly inline other functions regardless, and may choose <em>not</em> to inline some functions even when the programmer declared them as <code>inline</code>.</p>
<p>If a <code>packed</code> keyword is treated as a hint then it would not add that much value to the language, since the compiler won't follow it strictly; on the other hand, if a <code>packed</code> keyword forces the compiler to use a packed layout, then it prevents the compiler from choosing an optimal layout and there is a real risk that most programmers will use the keyword incorrectly. (Some will even think that <code>packed</code> means &quot;optimise the struct better&quot; and blindly apply it to every struct, resulting in worse performance more often than not.)</p>
<hr />
<p>Optimisation is not the only reason users may want control over the memory layout of their structs; binary compatibility is also an important issue when data needs to be passed over a network, stored in particular file formats, transferred to the GPU, or so on. But a simple yes/no <code>packed</code> keyword doesn't provide much control over this; for example, it doesn't help programmers who <em>need</em> to insert padding in particular places for correctness reasons.</p>
<p>For these other use-cases, it would be more valuable to offer a mechanism for the programmer to choose the exact layout of their structs, rather than just ask for sequential packing. Using <a href="https://en.wikipedia.org/wiki/OpenGL_Shading_Language" rel="noreferrer">GLSL</a> as an example, the <a href="https://www.khronos.org/opengl/wiki/Layout_Qualifier_(GLSL)" rel="noreferrer"><code>layout</code> qualifier</a> can be used to specify the exact offsets of struct fields. (This qualifier is necessarily attached to individual fields, rather than the struct as a whole.)</p>

CC BY-SA 4.0
2023-05-22T07:34:00.967Z
2023-05-22T07:34:00.967Z
kaya3
CC BY-SA 4.0
2024-03-27T17:45:40.530Z
Smaller structure sizes do generally improve speed, by fitting more working data in lower-level caches, and improve power use by reducing data traffic. However, packing alone isn’t a good way to achieve this—good data structure design, such as reducing indirection, is much more important.
Jon Purdy
CC BY-SA 4.0
2024-03-27T18:11:06.830Z
@JonPurdy They often do, but in general they don't. [Here's a typical example in Rust](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=95bcbfbc801c5790436f70031c916081) where a struct holds less than 16 bytes of actual data, but is padded out to 24 bytes so that its fields are properly aligned. The compiler does this because misaligned reads are slower. It's true that optimising for speed often entails using less memory (for fewer cache misses), but the point here is that speed is the objective, and when that means using more memory, the compiler will prioritise speed.
kaya3
CC BY-SA 4.0
2024-03-27T18:46:58.397Z
Yes, that’s what I’m saying: packing can undermine performance even though a smaller working set is desirable.
Jon Purdy
<p>I see no harm in including this as an optional feature, but be aware of performance issues that could be caused using this.</p>
<p>Many processors do not support many operations on non-aligned data. For example, adding 1 to a misaligned int <code>a</code> may involve something like this:</p>
<ul>
<li>Load the aligned section containing the first half of the number into one register</li>
<li>Load the aligned series of bytes containing the second half into another register</li>
<li>Bit shift each register so it contains only the parts corresponding to the number you want to edit</li>
<li>Use bitwise OR to combine them into one number</li>
<li>Add 1</li>
<li>Use AND with a mask to separate it into 2 halves again</li>
<li>Shift them back into their original position</li>
<li>Mask the part of each section you do not want to modify and OR it</li>
<li>Write each half back to its aligned memory slot</li>
</ul>
<p>While on the other hand if the data is aligned you can just add 1 in one step, overall easily 10x faster. Even on processor architectures that do support unaligned load and store, it will be slower, though not by quite as much.</p>
<p>Of course there are good reasons a developer might want to use it, like a large list of data that is rarely accessed. This should not be default, though, and you should warn developers about its use.</p>
<p>There is also a precedent; Rust has <code>#[repr(packed)]</code> which isn't quite what you are suggesting but serves much the same purpose.</p>

CC BY-SA 4.0
2023-05-22T06:59:53.580Z
2024-07-28T10:23:05.060Z
2024-07-28T10:23:05.060Z
mousetail 'he-him'
<p>There's not really any need for this feature, and using it could cause performance issues (e.g. requiring extra memory fetches and realignment for each item, or even a memory fault).</p>
<p>In situations where minimizing the size <em>is</em> important, the programmer would simply define the struct in an appropriate way based on the alignment requirements of the target architecture.</p>
<p>Generally: define the fields in the order of the size of their basic type.
The first field will naturally have proper alignment, and all following fields will also get proper alignment if their natural size is not larger than their preceding field.</p>
<p>This structure should contain no padding, except possibly at the end:</p>
<pre><code>typedef struct {
    long double f1;
    double f2;
    long long i1;
    float f3;
    long i2;
    int i3;
    short i4;
    char s1[3];
} MyStruct;
#define MYTEST() (assert(sizeof(MyStruct) == 48)
</code></pre>
<p>And then invoke MYTEST() at the beginning of the test program, since the 48 and the appropriate order might change from one architecture to another.</p>
<p>Or even simpler:</p>
<pre><code>#include &lt;static.h&gt;
…
} Mystruct;
static_assert(sizeof(MyStruct) == 48);
</code></pre>
<p>and the test will be done at compile time.</p>

CC BY-SA 4.0
2023-05-22T13:22:57.793Z
2024-03-27T02:30:29.547Z
2024-03-27T02:30:29.547Z
Ray Butterworth
CC BY-SA 4.0
2024-07-31T00:26:49.763Z
Packed structs are at least semi-required when their layout is forced to match some externally-defined layout that can only be attained with a packed struct. You could hack around the lack of support for packed structs by splitting a field into bytes.. gross
user555045
# What are the implications of a 'packed' keyword/feature?
Posted by: username_0 on 2023-05-22
I am bothered by the fact that, in C, struct types can be arbitrarily large. We have no control over their memory layout except for the fact that the first member is always at the beginning of the memory and the elements are arranged in the order we defined them in. A 'conforming' but never to be seen in practice C implementation may handle a struct as follows:
struct S {
    char x; // 1 byte
    // 999999999 bytes padding
    char y; // 1 byte
    // 999999999 bytes padding
    short z; // 2 bytes
    // 999999998 bytes padding
}; // Total size: 3 GB

To solve such problems, I am considering implementing a packed keyword to my programming language. packed struct would require using the least amount of space with no padding, and that all elements immediately follow each other. packed enum would use the smallest type that can hold all enumerators instead of some default type such as int.
What are the implications to implementing such a feature? Are there reasons, performance, compatibility, or otherwise, to refrain?
**Tags:** data-structures struct-packing
> **Comments:**
> **username_1**: Implicit in any useful programming language is that any implementation will do its best to be as efficient as it can be.  So padding will only be introduced if it makes things more efficient, and such silly paddings like you describe, while technically "legal" according to the spec, will not happen.  
---
## 7 answers
### Answer by username_5 on 2023-12-14. Score: 10 | Accepted answer
Padding and Packing
The layout of structures is defined by the ABI (Application Binary Interface). The typical mindset of an ABI designer is mechanical sympathy, with an eye towards performance (speed).
To talk about padding, we need to talk about alignment, size, and stride.
First is alignment. Native types tend to have an alignment, that is the architecture expects that a double is either 4 or 8 bytes aligned (depending). This alignment then bleeds into compound types: the only way to ensure that a double field is 8 bytes aligned is for the compound type containing the field to itself by 8 bytes aligned, hence a compound type's alignment is the greater alignment of any of its components.
Second is size. Native types have a size, too. For example a double is typically 8 bytes. The size of the compound type will depend on the size and alignment of its components, as per the ABI rules.
Finally is stride. The stride of a type is the spacing between consecutive array elements. Swift is one of the few languages differentiating size and stride, in C the stride is always the size.
With that in mind, here is a typical product type ABI, as can generally be found in C:

The alignment of the product type is the maximum alignment of any of its fields.
The first field starts at the first byte of its product type.
Any subsequent field starts at the next offset which guarantees its alignment, which may lead to "in-between" padding bytes.
The size of the struct is rounded-up to a multiple of its alignment, which may lead to "tail" padding bytes.

And since a picture is clearer than words:
struct ProductType {
    int i;
    char __padding_0[P0];
    double d;
    char __padding_1[P1];
    char c;
    char __padding_2[P2];
};

On x64, we have:

int: 4 bytes, 4-bytes aligned.
double: 8 bytes, 8-bytes aligned.
char: 1 byte, 1-byte aligned.

Therefore:

P0 = 4. This is because d must start at an offset that is a multiple of 8, and after i the offset is only 4.
P1 = 0. This is because c must start at an offset that is a multiple of 1, and any offset is.
P2 = 7. This is because the alignment of ProductType is 8, hence its size must be a multiple of 8.

Note that Swift would have P2 = 0.
The effect of packing is, very simply, to remove all padding.1
1 I am aware that some compilers take the opportunity to also allow specifying the struct alignment when packing. That's a potentially useful extra feature, but it's not packing.
Implications of Packing
The first and foremost implication is that you should implement it properly, or users will curse you.
For example, it seems reasonable to allow taking a reference (or pointer) to a field of a packed struct. However, this reference (or pointer) may now be under-aligned: that is, its alignment may be strictly less than the expected alignment of a pointer of this type.
Different languages & toolchains handle the situation differently:

In Zig, pointer alignment is a part of the pointer type, so a compilation error will follow if one attempts to use an under-aligned pointer where a regular pointer is expected.
In GCC (C or C++), the compiler handles under-aligned pointers properly within the function in which the pointer was created, but allows passing the under-aligned pointers to functions expecting a regular pointer... which leads to Undefined Behavior.
In Rust, manipulating packed fields is unsafe, and the user is on the hook to tread carefully, or they will trigger Undefined Behavior.

I would argue that the situation of being able to create an under-aligned pointer, but then have to walk on eggshells forever, is not desirable from a user point of view, and thus that language designers going the packed way should either disallow forming such pointers, or follow through and ensure they provide users the tooling they need to manipulate under-aligned pointers.
Alternatives
There are alternatives to packing, for the memory conscious.
As mentioned, packing is about avoiding padding, and there are two sources of padding:

In-between fields padding.
Tail padding.

Tail padding is eliminated in a language such as Swift which differentiates size & stride.
In-between fields padding is eliminated in a language such as Rust which reserves the right to re-order fields arbitrarily -- and typically will reorder them by descending alignment, which removes all in-between fields padding.
Those two alternatives, combined, remove nearly2 any and all padding in a struct3 without introducing under-aligned references and pointers into the fray.
I would typically advise considering them first:

Provide the same memory gains as packed, without taxing the user.
Without performance penalty incurred from under-aligned pointers.
Without headaches induced by under-aligned pointers.

You may still want to later introduce under-aligned pointers in the language, separately.
2 Unless reordering can interleave the fields from different field structs, there may still be some padding in between structs. For example, a struct A (int, char) followed by itself would still have 3 bytes of padding between the two instances, no matter the order.
3 Padding may still occur between array elements, the exact amount of padding inserted being equal to stride - size.
---
### Answer by username_6 on 2023-05-22. Score: 9
According to [“The Lost Art of Structure Packing” by Eric S. Raymond](https://www.catb.org/esr/structure-packing/), structure packing can slow down your program or worse:

> The first thing to understand is that, on modern processors, the way your compiler lays out basic datatypes in memory is constrained in order to make memory accesses faster. Our examples are in C, but any compiled language generates code under the same constraints.
>
> …
>
> Self-alignment [that is, aligning to an address divisible by the size of the datatype] makes access faster because it facilitates generating single-instruction fetches and puts of the typed data. Without alignment constraints, on the other hand, the code might end up having to do two or more accesses spanning machine-word boundaries.
>
> …
>
> I said “on modern processors” because on some older ones forcing your C program to violate alignment rules (say, by casting an odd address into an int pointer and trying to use it) didn’t just slow your code down, it caused an illegal instruction fault.

On the other hand, structure packing is useful “if you intend to write code for memory-constrained embedded systems, or operating-system kernels. It is useful if you are working with application data sets so large that your programs routinely hit memory limits. It is good to know in any application where you really, really care about optimizing your use of memory bandwidth and minimizing cache-line misses.” Raymond goes on to describe a program of his that kept getting OOM errors, for which he managed “to cut the working-set size by around 40%” by carefully arranging his structures.
---
### Answer by username_7 on 2023-05-22. Score: 6
Generally, compilers optimise for program speed rather than memory use. This is because in typical desktop and laptop PCs, memory is abundant, and a suboptimal struct layout won't waste that much memory; even a naive compiler should not make a struct take up more than twice as much space as necessary. On the other hand, optimising the execution speed of the program can easily yield improvements by much greater factors than two.

---

Another issue is that modern compilers are often better able to know whether an optimisation is worth applying, than the human writing the code. When languages allow the programmer to provide optimisation hints, like an `inline` keyword for functions, these are typically just treated as hints and the compiler will gladly inline other functions regardless, and may choose *not* to inline some functions even when the programmer declared them as `inline`.

If a `packed` keyword is treated as a hint then it would not add that much value to the language, since the compiler won't follow it strictly; on the other hand, if a `packed` keyword forces the compiler to use a packed layout, then it prevents the compiler from choosing an optimal layout and there is a real risk that most programmers will use the keyword incorrectly. (Some will even think that `packed` means "optimise the struct better" and blindly apply it to every struct, resulting in worse performance more often than not.)

---

Optimisation is not the only reason users may want control over the memory layout of their structs; binary compatibility is also an important issue when data needs to be passed over a network, stored in particular file formats, transferred to the GPU, or so on. But a simple yes/no `packed` keyword doesn't provide much control over this; for example, it doesn't help programmers who *need* to insert padding in particular places for correctness reasons.

For these other use-cases, it would be more valuable to offer a mechanism for the programmer to choose the exact layout of their structs, rather than just ask for sequential packing. Using [GLSL](https://en.wikipedia.org/wiki/OpenGL_Shading_Language) as an example, the [`layout` qualifier](https://www.khronos.org/opengl/wiki/Layout_Qualifier_(GLSL)) can be used to specify the exact offsets of struct fields. (This qualifier is necessarily attached to individual fields, rather than the struct as a whole.)
> **Comments:**
> **username_8** (2024-03-27): Smaller structure sizes do generally improve speed, by fitting more working data in lower-level caches, and improve power use by reducing data traffic. However, packing alone isn’t a good way to achieve this—good data structure design, such as reducing indirection, is much more important.  
> **username_7** (2024-03-27): @JonPurdy They often do, but in general they don't. [Here's a typical example in Rust](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=95bcbfbc801c5790436f70031c916081) where a struct holds less than 16 bytes of actual data, but is padded out to 24 bytes so that its fields are properly aligned. The compiler does this because misaligned reads are slower. It's true that optimising for speed often entails using less memory (for fewer cache misses), but the point here is that speed is the objective, and when that means using more memory, the compiler will prioritise speed.  
> **username_8** (2024-03-27): Yes, that’s what I’m saying: packing can undermine performance even though a smaller working set is desirable.  
---
### Answer by username_9 on 2023-05-22. Score: 5
I see no harm in including this as an optional feature, but be aware of performance issues that could be caused using this.

Many processors do not support many operations on non-aligned data. For example, adding 1 to a misaligned int `a` may involve something like this:

* Load the aligned section containing the first half of the number into one register
* Load the aligned series of bytes containing the second half into another register
* Bit shift each register so it contains only the parts corresponding to the number you want to edit
* Use bitwise OR to combine them into one number
* Add 1
* Use AND with a mask to separate it into 2 halves again
* Shift them back into their original position
* Mask the part of each section you do not want to modify and OR it
* Write each half back to its aligned memory slot

While on the other hand if the data is aligned you can just add 1 in one step, overall easily 10x faster. Even on processor architectures that do support unaligned load and store, it will be slower, though not by quite as much.

Of course there are good reasons a developer might want to use it, like a large list of data that is rarely accessed. This should not be default, though, and you should warn developers about its use.

There is also a precedent; Rust has `#[repr(packed)]` which isn't quite what you are suggesting but serves much the same purpose.
---
### Answer by username_10 on 2023-05-22. Score: 5
There's not really any need for this feature, and using it could cause performance issues (e.g. requiring extra memory fetches and realignment for each item, or even a memory fault).
In situations where minimizing the size is important, the programmer would simply define the struct in an appropriate way based on the alignment requirements of the target architecture.
Generally: define the fields in the order of the size of their basic type.
The first field will naturally have proper alignment, and all following fields will also get proper alignment if their natural size is not larger than their preceding field.
This structure should contain no padding, except possibly at the end:
typedef struct {
    long double f1;
    double f2;
    long long i1;
    float f3;
    long i2;
    int i3;
    short i4;
    char s1[3];
} MyStruct;
#define MYTEST() (assert(sizeof(MyStruct) == 48)

And then invoke MYTEST() at the beginning of the test program, since the 48 and the appropriate order might change from one architecture to another.
Or even simpler:
#include 
…
} Mystruct;
static_assert(sizeof(MyStruct) == 48);

and the test will be done at compile time.
> **Comments:**
> **username_11** (2024-07-31): Packed structs are at least semi-required when their layout is forced to match some externally-defined layout that can only be attained with a packed struct. You could hack around the lack of support for packed structs by splitting a field into bytes.. gross  
---
### Answer by username_2 on 2023-12-14. Score: 2
More useful than a `packed` keyword would be a more *general* means of specifying that a blob of memory should be treated as a structure with a precisely-specified layout which might be relied upon by outside code. Code which repeatedly assesses data items within such a structure would generally be slower than code which converts a structure's contents to an implementation's "native" numeric formats, manipulates them, and converts them back, but if it's only necessary to manipulate a small portion of the data structure, the overhead of performing such manipulation "in place" may be less than the cost of performing a round-trip conversion on the entire structure. Note that even if a field uses a format inconsistent with a platform's normal numeric formatting (e.g. a big-endian field on a little-endian platform), it would be easier for an implementation given e.g. `thingie.woozle++;`, where `woozle` is a 32-bit big-endian value at offset 38 of a word-aligned structure, to generate efficient machine code to handle that task than to generate equally-good machine code for all of the ways programmers might try to accomplish that task without such a language feature.

Although situations in which the space savings of using a packed data structure would be relevant are rare, situations where it would be useful to treat a blob of data *which is formatted to fit the needs of some outside code* using the same syntax as native-format data are much more common, and a language which is intended to facilitate the writing of portable programs should include features to work with octet-based data in precisely-specified formats. Note that such features would be especially useful on implementations that don't use octet-based storage, since it would allow non-octet-based platforms to exchange information with octet-based systems using information-interchange code written for octet-based platforms.
> **Comments:**
> **username_3** (2023-12-15): This approach can be seen for example in Python, using tools such as the `struct` standard library module to `unpack` data from a `bytes` source and `pack` it back in.  
> **username_4** (2023-12-15): I think Ada has a feature like this.  
---
### Answer by username_4 on 2023-12-14. Score: 0
For precedent, Microsoft's compiler [has a pragma](https://learn.microsoft.com/en-us/cpp/preprocessor/pack) for that: `#pragma pack()`:

> To pack a class is to place its members directly after each other in memory. It can mean that some or all members can be aligned on a boundary smaller than the default alignment of the target architecture.
> [...]
> If you change the alignment of a structure, it may not use as much space in memory. However, you may see a loss of performance or even get a hardware-generated exception for unaligned access.

Also, R. Chen wrote [a page about #pragma pack](https://devblogs.microsoft.com/oldnewthing/20200103-00/?p=103290), packed with good insight and examples of generated code (pun forced). For example:

> Changing the default structure packing has another consequence: It changes the alignment of the structure itself. In this case, the #pragma pack(1) declares that the structure P can itself be placed at any byte boundary, instead of requiring it to be placed on a 4-byte boundary.

[Some](https://www.ibm.com/docs/en/zos/3.1.0?topic=descriptions-pragma-pack) [other](https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Structure-Layout-Pragmas.html) [compilers](https://releases.llvm.org/3.4/tools/clang/docs/UsersManual.html) also have or had similar pragmas. GCC also has  [`__attribute__ ((__packed__))`](https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Type-Attributes.html).
---
