title: Does C++ guarantee identical binary layout for "trivial" structs with a single trivial member?
body: <p>We have some strictly typed integer types in our project:</p>
  <pre><code>struct FooIdentifier {
    int raw_id; // the only data member
  
    // ... more shenanigans, but it stays a &quot;trivial&quot; type.
  };
  
  struct BarIdentifier {
    int raw_id; // the only data member
  
    // ... more shenanigans, but it stays a &quot;trivial&quot; type.
  };
  </code></pre>
  <p>Basically something as proposed <a href="https://embeddedartistry.com/blog/2020/09/28/strongly-typed-integers-and-registers-in-c/" rel="noreferrer">here</a> or similar to things used in a <a href="https://github.com/mpusz/units" rel="noreferrer">Unit Library</a>.</p>
  <p>These structs basically <em>are</em> integers, except to the type system.</p>
  <p>My question <em>here</em> now is: <strong>Does the C++ language guarantee that these types are layed out 100% equivalent in memory as a regular <code>int</code> would be?</strong></p>
  <p><strong>Note</strong>: Since I can statically check whether the types have the same size (i.e. no padding), I'm really only interested in the no-surprising-padding case. <sup>I should've added this note from the beginning</sup></p>
  <pre><code>// Precodition. If platform would yield false here, I'm not interested in the result.
  static_assert(sizeof(int) == sizeof(ID_t)); 
  </code></pre>
  <p>That is, <strong>does the following hold from a C++ Standard POV</strong>:</p>
  <pre><code>int integer_array[42] = {}; // zero init
  ID_t id_array[42] = {}; // zero init
  
  static_assert(sizeof(int) == sizeof(ID_t)); // Precodition. If platform would yield false here, I'm not interested in the result.
  
  const char* const pIntArrMem = static_cast&lt;const char*&gt;(static_cast&lt;const void*&gt;(integer_array));
  const char* const pIdArrMem = static_cast&lt;const char*&gt;(static_cast&lt;const void*&gt;(id_array));
  assert(0 == memcmp(pIntArrMem, pIdArrMem, sizeof(int))); // Always ???
  </code></pre>