Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It is guaranteed to be legal, given that the element type is standard-layout. Note: all references in the following are to the <a href="/questions/tagged/c%2b%2b11" class="post-tag" title="show questions tagged 'c++11'" rel="tag">c++11</a> standard.</p> <blockquote> <h3>8.3.4 Arrays [dcl.array]</h3> <p>1 - [...] An object of array type contains a contiguously allocated non-empty set of <code>N</code> subobjects of type <code>T</code>. [...]</p> </blockquote> <p>Regarding a <code>struct</code> with <code>N</code> members of type <code>T</code>,</p> <blockquote> <h3>9.2 Class members [class.mem]</h3> <p>14 - Nonstatic data members of a (non-union) class with the same access control are allocated so that later members have higher addresses within a class object. [...] Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other [...]<br/> 20 - A pointer to a standard-layout struct object, suitably converted using a <code>reinterpret_cast</code>, points to its initial member [...] and vice versa. [ Note: There might therefore be unnamed padding within a standard-layout struct object, but not at its beginning, as necessary to achieve appropriate alignment. —end note ]</p> </blockquote> <p>So the question is whether any alignment-required padding within a <code>struct</code> could cause its members not to be contiguously allocated with respect to each other. The answer is:</p> <blockquote> <h3>1.8 The C++ object model [intro.object]</h3> <p>4 - [...] An object of trivially copyable or standard-layout type shall occupy contiguous bytes of storage.</p> </blockquote> <p>In other words, a standard-layout <code>struct</code> <code>a</code> containing at least two members <code>x</code>, <code>y</code> of the same (standard-layout) type that does not respect the identity <code>&amp;a.y == &amp;a.x + 1</code> is in violation of 1.8:4.</p> <p>Note that <em>alignment</em> is defined as (<strong>3.11 Alignment [basic.align]</strong>) <em>the number of bytes between successive addresses at which a given object can be allocated</em>; it follows that alignment of a type <code>T</code> can be no greater than the distance between adjacent objects in an array of <code>T</code>, and (since <strong>5.3.3 Sizeof [expr.sizeof]</strong> specifies that <em>the size of an array of</em> n <em>elements is</em> n <em>times the size of an element</em>) <code>alignof(T)</code> can be no greater than <code>sizeof(T)</code>. Thus any <em>additional</em> padding between adjacent elements of a struct of the same type would not be <em>required</em> by alignment and so would not be countenanced by 9.2:14.</p> <hr> <p>With regard to AProgrammer's point, I would interpret the language in <strong>26.4 Complex numbers [complex.numbers]</strong> as requiring that the instantiations of <code>std::complex&lt;T&gt;</code> should behave as standard-layout types with regard to the position of their members, without being required to conform to all the requirements of standard-layout types.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload