|
== Structural padding ==
Assuming "padding" is strictly related to [[data structure alignment]], I move we place the information about padding deeper into the article, and change the concept from "padding" to ''alignment''. e.g. "The C compiler [[data structure alignment|aligns]] the members of a struct..." A lead section might better focus on the ''unique'' aspects. There are two things that are not unique about the coded padding example.
*Padding is not unique to structs if alignment is used throughout the executable. In case the compiler ''does'' align data types, member data types, and instructions and cooked data for the executable, then the compiler routine for byte padding a struct need not be called (assuming there is not some other addressing algorithm, unrelated to word size).
The lead section is misleading where it talks about ''what appears to be'' the (interesting) subject of '''the internals''' of structs. It reads as if struct members are unique in that that they ''alone'' are padded. But to the common reader, just starting out programming, or merely skimming the subject of data structures themselves, the only internal of a struct that ''might'' be interesting (a diversion in their case) is the conceptual '''size''' of a struct as a [[value type]], or the method of '''chaining''' the members to one another. The mention of padding refers to something deeper{{mdash}}compiler design, specifically [[data structure alignment]]: {{quote|A memory pointer that refers to primitive data that is n bytes long is said to be aligned if it is only allowed to contain addresses that are n-byte aligned, otherwise it is said to be unaligned. A memory pointer that refers to a data aggregate (a data structure or array) is aligned if (and only if) each primitive datum in the aggregate is aligned.}} Thus byte padding is not really ''implemented'' upon structures, or between structures. They are just input and output, and words themselves are the padding that separate bytes. If the compiler aligns the data, both the primitives alone and the primitives inside the composites, then '''the concept of padding''' reduces to the concept of words: the first bytes are aligned on a sort of word-grid. Padding is then just a side-effect of the subject of alignment, not of structures themselves. It is not unlike bits in a byte. Padding is not spoken of in that context, nor should it be in our context.
*The internal alignment of data members is not unique to the C struct. There is an analogous dynamic that also "works as expected" concerning subclassing in C++. That said it is very interesting that even if a C compiler is run "unaligned" it will always align (don't say "pad"?) struct members ''inside'' the struct, guaranteeing this manipulation by a sub-struct of quantity N-last elements manipulating its containing struct of N elements.
Salient internals for our lead section are the '''size''' (as mentioned), and the method of '''chaining''' the members of a C struct to one another.
I move we place "If the C compiler [[data structure alignment|aligns]] the members of a struct, then there is these neat trick that telecom programmers use..." deeper in the article, if it is not removed entirely. This concept is not unique to the C struct. There is an analogous dynamic that also "works as expected" concerning subclassing in C++. — [[User:Cpiral|<font color="#00C000">Cp</font><font color="#80C000">i</font><font color="#C08000">r</font><font color="#C00000">al</font>]][[User talk:Cpiral|<font color="#2820F0"><u>Cpiral</u></font>]] 21:31, 1 October 2011 (UTC)
— [[User:Cpiral|<font color="#00000">Cp</font><font color="#80C000">i</font><font color="#C08000">r</font><font color="#C00000">al</font>]][[User talk:Cpiral|<font color="#2820F0"><u>Cpiral</u></font>]] 21:31, 1 October 2011 (UTC)
| 