StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
12181316
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2012-08-29T15:22:33
FavoriteCount
0
LastActivityDate
2012-08-29T15:22:33
LastEditDate
2017-05-23T12:07:52.840
LastEditorUserId
-1
OwnerUserId
179910
ParentId
12138243
PostTypeId
2
Score
5
ViewCount
0
LastEditorDisplayName
text
Body
The standard is fairly specific that even a POD-struct (which is, I believe the most restrictive class of structs) can have padding between members. ("There might therefore be unnamed padding within a POD-struct object, but not at its beginning, as necessary to achieve appropriate alignment." -- a non-normative note, but still makes the intent quite clear). For example, contrast the requirements for a standard-layout struct (C++11, §1.8/4): <blockquote> An object of trivially copyable or standard-layout type (3.9) shall occupy contiguous bytes of storage." </blockquote> ...with those for an array (§8.3.4/1): <blockquote> An object of array type contains a contiguously allocated non-empty set of N subobjects of type T. </blockquote> In the array, the elements themselves are required to be allocated contiguously, whereas in the struct, only the storage is required to be contiguous. The third possibility that might make the "contiguous storage" requirement make more sense would be to consider a struct/class that is not trivially copyable or standard layout. In this case, it's possible that the storage might might not be contiguous at all. For example, an implementation might set aside one area of memory for holding all the private variables, and an entirely separate area of memory to hold all the public variables. To make that a little more concrete, consider two definitions like: <pre><code>class A { int a; public: int b; } a; class B { int x; public: int y; } b; </code></pre> With these definitions, the memory might be laid out something like: <pre><code>a.a; b.x; // ... somewhere else in memory entirely: a.b; b.y; </code></pre> In this case, neither the elements nor the storage needs to be contiguous, so interleaving parts of entirely separate structs/classes is allowable. That said, the first element must be at the same address as the struct as a whole (9.2/17): "A pointer to a POD-struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa." In your case, you have a POD-struct, so (§9.2/17): "A pointer to a POD-struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa." Since the first member must be aligned, and the remaining members are all of the same type, it's impossible for any padding to be truly necessary between the other members (i.e., except for bit-fields, any type you can put in a struct you can also put in an array, where contiguous allocation of the elements is required). If you have elements smaller than a word, on a word-oriented machine (e.g., early DEC Alphas), it's possible that padding could make access somewhat simpler though. For example, early DEC Alphas (at the hardware level) were only capable of reading/writing an entirely (64-bit) word at a time. As such, let's consider something like a struct of four <code>char</code> elements: <pre><code>struct foo { char a, b, c, d; }; </code></pre> If it was required to lay these out in memory so they were contiguous, accessing a <code>foo::b</code> (for example) would require that the CPU load the word, then shift it 8-bits right, then mask to zero-extend that byte to fill the entire register. Storing would be even worse -- the CPU would have to load the current value of the whole word, mask out the current contents of the appropriate char-sized piece of that, shift the new value to the correct place, OR it into the word, and finally store the result. By contrast, with padding between the elements, each of those becomes a simple load/store, with no shifting, masking, etc. At least if memory serves, with DEC's normal compiler for the Alpha, <code>int</code> was 32 bits, and <code>long</code> was 64 bits (it predated <code>long long</code>). As such, with your struct of four <code>int</code>s, you could have expected to see another 32 bits of padding between the elements (and another 32 bits after the last element as well). Given that you do have a POD-struct, you still have some possibilities though. The one I'd probably prefer would be to use <code>offsetof</code> to get the offsets of the members of the struct, create an array of them, and access the members via those offsets. I showed how to do this in a <a href="https://stackoverflow.com/a/5088496/179910">couple</a> of <a href="https://stackoverflow.com/a/2043949/179910">previous answers</a>.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POCast A primitive type pointer to A structure pointer - Alignment and Padding?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USCommunity
UserOwnerUserId
1. USJerry Coffin
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POCast A primitive type pointer to A structure pointer - Alignment and Padding?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COThat architecture would not be conformant; 1.7:3 *Two or more threads of execution can update and access separate memory locations without interfering with each other*. To make such an architecture conformant, `char` would have to be 64 bits.
 singulars
 PostPostId
 PO
 UserUserId
 USecatmur
2. CO@ecatmur: Could be -- obviously DEC was long gone by the time C++11 was approved (and I doubt HP's going to put a lot of work into C++11 compliance for the Alpha). In any case, at least as I read it, "without interfering" still only requires that the modification be surrounded by a critical section (which it probably was -- the Alpha was heavily oriented toward supporting threads).
 singulars
 PostPostId
 PO
 UserUserId
 USJerry Coffin

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.