<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>POD's Revisited</title>
</head>

<body>

<p>Doc. no.&nbsp;&nbsp;
WG21/N2102=06-0172<br>
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%Y-%m-%d" startspan -->2006-10-31<!--webbot bot="Timestamp" endspan i-checksum="12039" --><br>
Project:&nbsp;&nbsp;&nbsp;&nbsp; Programming Language C++<br>
Reply to:&nbsp;&nbsp; Beman Dawes &lt;<a href="mailto:bdawes@acm.org">bdawes@acm.org</a>&gt;</p>

<h1>POD's Revisited; Resolving Core Issue 568 (Revision 1)</h1>

<p><a href="#Introduction">Introduction</a><br>
<a href="#Summary">Summary of proposed changes</a><br>
<a href="#To-Do">To Do</a><br>
<a href="#Features">Features and benefits of POD types</a><br>
<a href="#Motivating-examples">Motivating examples</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#std::pair-example">std::pair example</a><br>
&nbsp;&nbsp;&nbsp; <a href="#Endian-example">Endian example</a><br>
&nbsp;&nbsp;&nbsp; <a href="#Two-structs-example">Two structs example</a><br>
&nbsp;&nbsp;&nbsp; <a href="#Atomic">Atomic example</a><br>
<a href="#Coupling">Coupling between POD's and aggregates</a><br>
<a href="#Rationale">Rationale for changes</a><br>
<a href="#Proposed">Proposed changes to the Working Paper</a><br>
&nbsp;&nbsp;&nbsp; <a href="#POD-in-Standard">POD in the Standard, with changes</a><br>
<a href="#Impact">Impact on existing code</a><br>
<a href="#ABI">Impact on existing ABI's</a><br>
<a href="#Interaction">Interactions with other proposals</a><br>
<a href="#Revision-history">Revision history</a><br>
<a href="#Acknowledgements">Acknowledgements</a><br>
<a href="#References">References</a></p>

<h2><a name="Introduction">Introduction</a></h2>

<p>This paper proposes a resolution for
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2029.html#568">Core 
Issue 568</a>, <b>Definition of POD is 
too strict,</b> submitted by Matt Austern.</p>

<p>POD's as defined in the current working paper has several problems:</p>

<ul>
  <li><i><b>Overly strict requirements.</b></i> This forces users to make unwise 
  design choices, such as reliance on undefined behavior. 
  See <a href="#Motivating-examples">Motivating examples</a>.<br>
&nbsp;</li>
  <li><i><b>Coupling between POD's and aggregates.</b></i> The current 
  definition of POD depends by reference on the definition of aggregate, causing 
  several difficulties. See <a href="#Coupling">Coupling between POD's and 
  aggregates</a>.<br>
&nbsp;</li>
  <li><b><i>Coupling between trivial special member function needs and other needs.</i></b> 
  The Standard describes requirements as POD or non-POD in many places where 
  trivial construction, copy, assignment, and destruction is the only actual concern. Separating these 
  needs would result in a cleaner specification.</li>
</ul>

<h2><a name="Summary">Summary</a> of proposed changes</h2>
<ul>
  <li>POD's are now defined in terms of two new categories of types; trivial 
  classes and standard-layout classes.</li>
  <li>The definition of these types no longer depends on the definition of 
  aggregate.</li>
  <li>POD's and trivial classes are now allowed to have constructors. Default 
  constructors with effects, and copy constructors, are still not allowed.</li>
  <li>POD's, trivial types, and standard-layout types are now allowed to have base classes. The base classes are not 
  allowed to have non-static data members, virtual members, or virtual bases.</li>
  <li>POD's and standard-layout types are now allowed to have access control. All non-static data members 
  must have the same access control.</li>
  <li>Most uses of POD in the WP were found to actually be concerned with only trivial or standard-layout 
  types. Such uses have been changed accordingly.</li>
</ul>
<h2><a name="To-Do">To Do</a></h2>
<p>The current language rules for initialization (<a href="#8.5/5">8.5</a>) 
sometimes require POD types. In this proposal, such requirements have been 
relaxed to only require trivial types. It is anticipated that these rules can be 
further refined and relaxed, but that work is deferred pending proposed wording 
to implement the
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2100.pdf">
N2100 Initializer lists</a> proposal.</p>

<h2><a name="Features">Features</a> and benefits of POD types</h2>

<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%">
  <tr>
    <td width="50%" align="center"><b><i>Features</i></b></td>
    <td width="50%" align="center"><i><b>Benefits</b></i></td>
  </tr>
  <tr>
    <td width="50%" valign="top">Byte copyable guarantees [<a href="#3.9/2">3.9<b><i> <font face="Times New Roman"></font></i></b>2-3, basic.types</a>]</td>
    <td width="50%">
    <ul>
      <li>Programs can safely apply coding optimizations, particularly <code>
  std::memcpy</code>.</li>
    </ul>
    </td>
  </tr>
  <tr>
    <td width="50%" valign="top">C layout-compatibility guarantees, byte copyable 
    guarantees [<a href="#class.mem">9.2<b><i> <font face="Times New Roman"></font></i></b>14-17, class.mem</a>], 
    initialization rules.</td>
    <td width="50%"><ul>
  <li>C++ programs can interoperate with 
  functions written in C and other languages.</li>
  <li>C++ programs can, after considering compiler, alignment, and data type 
  constraints, perform binary I/O such that files to interoperate with other 
  languages and platforms.</li>
  <li>C language compatibility.</li>
  </ul>

    </td>
  </tr>
  <tr>
    <td width="50%" valign="top">Static initialization guarantees [<a href="#3.6.2">3.6.2, 
    basic.start.init</a>]</td>
    <td width="50%">
    <ul>
      <li>Programs can avoid order-of-initialization issues.</li>
      <li>Multi-threaded programs can avoid data races during initialization.</li>
    </ul>
    </td>
  </tr>
  <tr>
    <td width="50%" valign="top">Are aggregates</td>
    <td width="50%">
    <ul>
      <li>Brace-enclosed initializer lists allowed.</li>
    </ul>
    </td>
  </tr>
  <tr>
    <td width="50%" valign="top">Various rules for non-POD's</td>
    <td width="50%">
    <ul>
      <li>Compilers  apply data layout optimizations to non-POD's.</li>
      <li>Compilers  assume non-aliasing, allowing code generation 
      optimizations for non-POD's. </li>
    </ul>
    </td>
  </tr>
</table>

<h2><a name="Motivating-examples">Motivating examples</a></h2>

<h3><a name="std::pair-example"><code>std::pair</code> example</a></h3>

<p>Matt Austern provided this example:</p>

<p>If a program has two arrays of type <code>std::pair&lt;int,int&gt;</code>, then it 
is natural to expect that <code>memcpy(A2,A1,sizeof(A2))</code> would be safe. 
Programmers have trouble imagining any implementation in which a byte-for-byte 
copy of <code>std::pair&lt;int,int&gt;</code> wouldn't do the right thing. 
Unfortunately, that's not what the language standard says. It says that 
byte-for-byte copies are guaranteed to work only for PODs. <code>std::pair&lt;T,U&gt;</code> 
isn't a class aggregate, since it has a user-defined constructor, and that means 
it also isn't a <span id="st" name="st" class="st">POD</span>.<br>
<br>
<code>std::pair </code>has a user-defined constructor essentially for syntactic 
reasons: because in some cases it looks nicer to write &quot;<code>std::pair&lt;int,int&gt; 
p(1,2);</code>&quot; than to write &quot;<code>std::pair&lt;int,int&gt; p = {1,2};</code>&quot;. It 
seems a shame that this syntactic change caused the loss of the important 
semantic property of PODness. It's especially a shame because it means something 
formally doesn't work when on all real-world implementations it actually does 
work. It also encourages programmers to rely on undefined behavior, which is 
something the standard should not encourage.</p>

<p>With the <a href="#Proposed">proposed resolution</a>, the example pair becomes a POD, solving the issue.</p>

<h3><a name="Endian-example">Endian example</a></h3>

<p>Beman Dawes provided this example:</p>

<p>Here is an example of something in development for Boost, based on classes 
used in industrial applications for many years. The fact that it is 
a template partial specialization isn't material to this discussion and 
can be ignored.</p>
<blockquote>
  <pre>template &lt;typename T, std::size_t n_bits&gt;
class endian&lt; big, T, n_bits, unaligned &gt; : cover_operators&lt; endian&lt; big, T, n_bits &gt;, T &gt;
{
  BOOST_STATIC_ASSERT( (n_bits/8)*8 == n_bits );
public:
  typedef T value_type;
  endian() {}
  endian(T i) { detail::store_big_endian&lt;T, n_bits/8&gt;(bytes, i); }
  operator T() const { return detail::load_big_endian&lt;T, n_bits/8&gt;(bytes); }
private:
  char bytes[n_bits/8];
};</pre>
</blockquote>
<p>But it isn't a POD, so it won't work at all in unions and  uses such as 
binary I/O 
rely on undefined behavior. Since the primary rationale for the existence of
<code>endian</code> is to do 
binary I/O, forcing the user to rely on undefined behavior is unfortunate to say the least.</p>

<p>Here is what would have to be done to make it a POD:</p>

<blockquote>

<p><i><b>Remove the constructors.</b></i> But that makes initialization painful, 
so boosters are proposing to add an ugly and unintuitive static init function, and an <code>operator=</code> 
from the <code>value_type</code>. Those are partial workarounds, but not really what the 
designers, Beman Dawes and Darin Adler,&nbsp;wanted.</p>

<p><b><i>Make the data member public.</i></b> But this encourages a poor design 
practice.</p>

<p><b><i>Eliminate the base class.</i></b> But the only way to do that without 
the highly error-prone duplication of the functions provided by the base class 
is to introduce a lengthy macro. Enough said.</p>

</blockquote>

<p>In other words, making this class a POD under current language rules would do serious 
damage to interface ease-of-use and to code quality, and would encourage poor 
design practices. Yet the only data member in the class is an array of char, so 
programmers intuitively expect the class to be memcpyable and binary I/O-able.</p>

<p>With the <a href="#Proposed">proposed resolution</a>, the class becomes a POD, solving all the issues.</p>

<h3><a name="Two-structs-example">Two structs example</a></h3>

<p>Matt Austern provided this example in Core DR 568:</p>

<p>Its silly for the standard to make layout and memcpy guarantees for this 
class:</p>

<blockquote>
  <pre>struct A {
  int n;
};</pre>
</blockquote>
<p>but not for this one:</p>
<blockquote>
  <pre>struct B {
  int n;
  B(n_) : n(n_) { }
};</pre>
</blockquote>
<p>With either A or B, it ought to be possible to save an array of those objects 
to disk with a single call to Unixs write(2) system call or the equivalent. At 
present the standard says that its legal for A but not B, and there isnt any 
good reason for that distinction.</p>

<p>With the <a href="#Proposed">proposed resolution</a>, the class becomes a POD, solving all the issues.</p>

<h3><a name="Atomic">Atomic</a> example</h3>

<p>Lawrence Crowl provided this example.</p>

<p>Consider a class providing atomic operations. Among other requirements, it 
should:</p>

<ul>
  <li>Be C-layout compatible.</li>
  <li>Be non-copyable.</li>
</ul>

<p>For best C++ coding practice, the data should be private and the usual copy 
constructor and copy assignment idioms used to make the class non-copyable. But 
that would make the class a non-POD under current rules. </p>

<p>With the <a href="#Proposed">proposed resolution</a>, the class becomes a 
standard-layout class, solving both issues.</p>

<h2><a name="Coupling">Coupling</a> between POD's and aggregates</h2>

<p>POD's provide object representation guarantees, 
layout-compatibility guarantees, memory contiguity guarantees, and memory 
copy-ability guarantees for fairly simple types, yet leave compilers much 
latitude in such matters for more complicated types.</p>

<p>Aggregates provide well-defined initialization from <i>initializer-clauses</i>.</p>

<p>The two concepts are at most tangential, if not completely orthogonal. Thus 
to define POD in terms of aggregates creates an unnecessary and confusing 
dependency. It makes otherwise straightforward changes to the Standard POD and 
aggregate sections much more difficult because of the need to analyze a potential 
change for impact on both POD's and aggregates. The coupling is confusing to users, 
causing them to make mistaken assumptions about POD's. The coupling may be part 
of the reason even committee members cannot accurately remember the full rules 
for POD-ness.</p>

<h2><a name="Rationale">Rationale</a> for changes</h2>

<p>The proposed changes decompose the current POD requirements into <i>trivial</i> 
type requirements and <i>standard-layout</i> type requirements, and remove the dependency on the 
definition of aggregates. Because these decomposed requirements are somewhat less restrictive 
than the requirements for aggregates, the effect is to make POD's more broadly 
useful and solve the problems identified in the <a href="#Introduction">
Introduction</a> and <a href="#Motivating-examples">
Motivating examples</a>. It also opens up the possibility of designing useful 
classes that meet one or the other, but not both, of the new trivial and 
standard-layout requirements.</p>

<p>As a consequence of&nbsp; allowing members of any access control in 
standard-layout types, the current requirement that POD data members have no 
intervening access-specifiers is changed to require only that such data members 
have the same access control. This change is believed to also be more in line 
with programmer expectations than the current requirements.</p>

<p>Changes are not proposed that would allow POD's to have base classes with 
non-static data members. There was no apparent way to allow these cases without 
putting undue restrictions on how compilers allocate base class data in relation 
to derived class data.</p>

<p>This table summaries the new decomposition of requirements:</p>

<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%">
  <tr>
    <td width="72%" align="center"><i><b>Requirement</b></i></td>
    <td width="16%" align="center"><i><b>Classes and types requirement applies 
    to</b></i></td>
  </tr>
  <tr>
    <td width="72%" valign="top">Trivial default constructor or default 
    constructor with no effects, trivial copy constructor, 
    trivial copy assignment, trivial destructor; ditto members and bases.</td>
    <td width="16%" valign="top"><i>trivial, POD</i></td>
  </tr>
  <tr>
    <td width="72%" valign="top">No virtual functions, no virtual bases</td>
    <td width="16%" valign="top"><i>trivial, standard-layout, POD</i></td>
  </tr>
  <tr>
    <td width="72%" valign="top">All non-static members have same access 
    control; no base classes with non-static data members; no non-static members 
    are references; non-static member arrays also meet requirements.</td>
    <td width="16%" valign="top"><i>standard-layout, POD</i></td>
  </tr>
</table>

<h2><a name="Proposed">Proposed</a> changes to the Working Paper</h2>

<p>Added text is shown in <u>
<font color="#228822">green and underlined</font></u>. Deleted text is shown 
in <strike><font color="#FF0000">red with strikethrough</font></strike>.</p>

<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="33%">
  <tr>
    <td width="100%">&nbsp;<i>Commentary is shown in boxed italics.</i></td>
  </tr>
</table>

<p><i>Since issue 538 is currently in review status,&nbsp; changes to clause 9 
paragraph 4 are shown relative to 538's proposed wording.</i></p>

<p>The following table lists all uses of POD, and related topics, in the current working paper, with 
proposed changes. Because the change to clause 9, paragraph 4,is critical to 
understanding the other changes, it is presented first.</p>

<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%">
  <tr>
    <td width="76%" align="center"><b><i>Working Paper Text</i></b></td>
  </tr>
  <tr>
    <td width="76%">

<p><b><i>9 <font face="Times New Roman"></font>4 Classes [class]</i></b></p>

<p>A <i>union</i> is a class defined with the <i>class-key</i> <tt>union</tt>; 
it holds only one data member at a time (9.5). [<i>Note:</i> aggregates of class 
type are described in 8.5.1. <i>end note</i>]</p>

<p><u>
<font color="#228822">A 
<i>trivial-class</i> is a class that has a trivial default constructor (12.1) or 
a default constructor defined in the class definition and having no effects, a trivial copy constructor (12.8),  a trivial copy assignment operator (13.5.3, 12.8), 
and a trivial destructor (12.4). [<i>Note:</i> That precludes 
virtual functions, virtual bases, and members or bases with non-trivial default 
constructors having effects, non-trivial copy 
constructors, non-trivial copy assignments, or non-trivial destructors. <i>
--end note</i>]</font></u></p>

<p><u><font color="#228822">A <i>standard-layout-class</i> is a class that:
</font></u></p>

<blockquote>

<p> <u><font color="#228822">has no non-static data members of type
non-standard-layout-class (or 
array of such types) or reference, and</font></u><br>
 <u><font color="#228822">has no virtual functions (10.3) and no virtual base 
classes (10.1), and</font></u><br>
 <u><font color="#228822">has the same access control (clause 11) for all non-static data members, and<br>
</font></u> <u><font color="#228822">has no non-standard-layout base classes, and no base classes with 
non-static data members.</font></u></p>

</blockquote>

<p><font color="#228822"><u>A <i>standard-layout-struct</i> is a standard-layout 
class defined with the <i>class-key</i> <tt>struct</tt> or the <i>class-key</i>
<tt>class</tt>. A <i>standard-layout-union</i> is a standard-layout class defined 
with the <i>class-key</i> <tt>union</tt>.</u></font></p>

<p><u><font color="#228822"><i>[Note:</i> Standard-layout classes are useful for 
communicating with code written in other programming languages. The layout is specified 
in 9.2. <i>-- end note</i>]</font></u></p>

<p>A <i>POD class</i> is <font color="#FF0000"> <strike>an aggregate</strike> </font>
<u><font color="#228822">a</font></u><font color="#FF0000"> </font>class that 
<font color="#228822"><u>is both a trivial class and standard-layout class, and</u></font> has no non-static data 
members of non-POD type (or array of such a type) or reference<strike><font color="#FF0000">, 
and has no user-declared copy assignment operator and no user-declared 
destructor</font></strike>. A <i>POD-struct</i> is a POD class defined with the
<i>class-key</i> <tt>struct</tt> or the <i>class-key</i> <tt>class</tt>. A <i>
POD-union</i> is a POD class defined with the <i>class-key</i> <tt>union</tt>.</p>

<p><font color="#228822"><i><u>[Example:</u></i></font></p>

<blockquote>
  <pre><font color="#228822"><u>struct N { // neither trivial nor standard-layout
</u>    <u>int i;
</u>    <u>int j;
</u>    <u>virtual ~N();
};

struct T { // trivial but not standard-layout
</u>    <u>int i;
private: 
</u>    <u>int j;
};

struct SL { // standard-layout but not trivial
</u>    <u>int i;
</u>    <u>int j;
</u>    <u>~LD();
};

struct POD { // both trivial and standard-layout
</u>    <u>int i;
</u>    <u>int j;
};</u></font></pre>
</blockquote>
<p><u><font color="#228822"><i>-- end example]</i></font></u></p>

<p>Similarly, a <i>
POD-union</i> is <strike><font color="#FF0000">an aggregate</font></strike>
<u><font color="#228822">a</font></u> union that has no 
non-static data members of type non-POD-struct, non-POD-union (or array of such 
types) or reference, and has no user-declared copy assignment operator 
and no user-declared destructor. A <i>
POD class</i> is a class that is 
either a POD-struct or a POD-union.<font color="#228822"><u><i> [Note:</i> virtual functions and base classes are 
prohibited in unions (9.5). <i>-- end note.]</i></u></font></p>

    </td>
  </tr>
  <tr>
    <td width="76%"><b><i>1.8 <font face="Times New Roman"></font>5 [intro.object]</i></b><p>
    Unless it is a bit-field (9.6), a most derived object shall have a non-zero 
    size and shall occupy one or more bytes of storage. Base class subobjects 
    may have zero size. An object of <strike><font color="#FF0000">POD type (3.9)</font></strike>
    <font color="#228822"><u>trivial or standard-layout 
    (clause 3.9) type</u></font> shall occupy contiguous bytes 
    of
    storage.</td>
  </tr>
  <tr>
    <td width="76%"><b><i><a name="3.6.2">3.6.2</a> 1 Initialization of non-local objects</i></b><p>
    Objects with static storage duration (3.7.1) shall be zero-initialized (8.5) 
    before any other initialization takes place. A reference with static storage 
    duration and an object of 
    <strike><font color="#FF0000">POD</font></strike> <font color="#228822"><u>
    trivial</u></font> type with static 
    storage duration can be initialized with a constant expression (5.19); this 
    is called <i>constant initialization.</i> Together, zero-initialization and 
    constant initialization are called <i>static initialization</i>; all other 
    initialization is <i>dynamic initialization</i>. Static initialization shall 
    be performed before any dynamic initialization takes place. Dynamic 
    initialization of an object is either ordered or unordered. Definitions of 
    explicitly specialized class template static data members have ordered 
    initialization. Other class template static data members (i.e., implicitly 
    or explicitly instantiated specializations) have unordered initialization. 
    Other objects defined in namespace scope have ordered initialization. 
    Objects defined within a single translation unit and with ordered 
    initialization shall be initialized in the order of their definitions in the 
    translation unit. The order of initialization is unspecified for objects 
    with unordered initialization and for objects defined in different 
    translation units. [<i> Note:</i> 8.5.1 describes the order in which 
    aggregate members are initialized. The initialization of local static 
    objects is described in 6.7. <i>end note</i> ]</td>
  </tr>
  <tr>
    <td width="76%"><b><i>3.8 2 Object Lifetime</i></b><p>&nbsp;[ Note: the lifetime of an array object or of an object of 
    <strike><font color="#FF0000">POD</font></strike> <font color="#228822"><u>
    trivial</u></font> type (3.9) starts as soon as storage with proper size and alignment is 
    obtained, and its lifetime ends when the storage which the array or object 
    occupies is reused or released. 12.6.2 describes the lifetime of base and 
    member subobjects. end note ]</td>
  </tr>
  <tr>
    <td width="76%"><b><i>3.8 5 Object Lifetime</i></b><p>Before the lifetime 
    of an object has started but after the storage which the object will occupy 
    has been allocated39) or, after the lifetime of an object has ended and 
    before the storage which the object occupied is reused or released, any 
    pointer that refers to the storage location where the object will be or was 
    located may be used but only in limited ways. Such a pointer refers to 
    allocated storage (3.7.3.2), and using the pointer as if the pointer were of 
    type void*, is well-defined. Such a pointer may be dereferenced but the 
    resulting lvalue may only be used in limited ways, as described below. If 
    the object will be or was of a class type with a non-trivial destructor, and 
    the pointer is used as the operand of a <i>delete-expression</i>, the 
    program has undefined behavior. If the object will be or was of a <strike>
    <font color="#FF0000">non-POD</font></strike> <u><font color="#228822">
    non-trivial</font></u> class type, the program has undefined behavior if:<p>
     the pointer is used to access a non-static data member or call a 
    non-static member function of the object, or<p> the pointer is implicitly 
    converted (4.10) to a pointer to a base class type, or<p> the pointer is 
    used as the operand of a static_cast (5.2.9) (except when the conversion is 
    to void*, or to void* and subsequently to char*, or unsigned char* )<p> the 
    pointer is used as the operand of a dynamic_cast (5.2.7).</td>
  </tr>
  <tr>
    <td width="76%"><b><i>3.8 6 Object Lifetime</i></b><p>Similarly, before the 
    lifetime of an object has started but after the storage which the object 
    will occupy has been allocated or, after the lifetime of an object has ended 
    and before the storage which the object occupied is reused or released, any 
    lvalue which refers to the original object may be used but only in limited 
    ways. Such an lvalue refers to allocated storage (3.7.3.2), and using the 
    properties of the lvalue which do not depend on its value is well-defined. 
    If an lvalue-to-rvalue conversion (4.1) is applied to such an lvalue, the 
    program has undefined behavior; if the original object will be or was of a
    <strike><font color="#FF0000">non-POD</font></strike> <u>
    <font color="#228822">non-trivial</font></u> class type, the program has undefined behavior if:<p>
     the lvalue is used to access a non-static data member or call a non-static 
    member function of the object, or<p> the lvalue is implicitly converted 
    (4.10) to a reference to a base class type, or<p> the lvalue is used as the 
    operand of a static_cast (5.2.9) except when the conversion is ultimately to 
    cv char&amp; or cv unsigned char&amp; ), or<p> the lvalue is used as the operand of 
    a dynamic_cast (5.2.7) or as the operand of typeid.</td>
  </tr>
  <tr>
    <td width="76%"><b><i><a name="3.9/2">3.9 2</a> Types</i></b><p>For any object (other than a base-class subobject) of 
    <strike><font color="#FF0000">POD</font></strike> <font color="#228822"><u>
    trivial</u></font> 
    type T, whether or not the object holds a valid value of type T, the 
    underlying bytes (1.7) making up the object can be copied into an array of 
    char or unsigned char.41) If the content of the array of char or unsigned 
    char is copied back into the object, the object shall subsequently hold its 
    original value.</td>
  </tr>
  <tr>
    <td width="76%"><b><i>3.9 3 Types</i></b><p>For any <strike>
    <font color="#FF0000">POD</font></strike> <font color="#228822"><u>
    trivial</u></font> type T, if two pointers to T point to distinct T 
    objects obj1 and obj2, where neither 
    obj1 nor obj2 is a base-class subobject,
    if the value of obj1 is copied into obj2, using the std::memcpy library 
    function, obj2 shall subsequently hold the same value as obj1.</td>
  </tr>
  <tr>
    <td width="76%"><b><i>3.9 4 Types</i></b><p>The object representation of an object of type T is the 
    sequence of N unsigned char objects taken up by the object of type T, where 
    N equals sizeof(T). The value representation of an object is the set of bits 
    that hold the value of type T. For <strike><font color="#FF0000">POD</font></strike>
    <font color="#228822"><u>trivial</u></font> types, the value representation is a 
    set of bits in the object representation that determines a value, which is 
    one
    discrete element of an implementation-defined set of values.42)</td>
  </tr>
  <tr>
    <td width="76%"><b><i>3.9 10 Types</i></b><p>Arithmetic types (3.9.1), enumeration types, pointer types, 
    and pointer to member types (3.9.2), and cv-qualified versions of these 
    types (3.9.3) are collectively called scalar types.<p>Scalar types, POD-struct 
    types, POD-union types (clause 9), arrays of such types and cv-qualified 
    versions of these types (3.9.3) are collectively called POD types.<p><u><font color="#228822">Scalar types, 
    trivial-class types (clause 9), arrays of such types and cv-qualified 
    versions of these types (3.9.3) are collectively called <i>trivial</i> 
    types.</font></u><p><u><font color="#228822">Scalar types, 
    standard-layout-class types (clause 9), arrays of such types and cv-qualified 
    versions of these types (3.9.3) are collectively called <i>standard-layout</i> 
    types.</font></u></td>
  </tr>
  <tr>
    <td width="76%"><i><b>3.9 11 Types</b></i><p>If two types T1 and T2 are the 
    same type, then T1 and T2 are layout-compatible types. [ Note: 
    Layout-compatible enumerations are described in 7.2. Layout-compatible 
    <strike><font color="#FF0000">POD-structs</font></strike> <u>
    <font color="#228822">standard-layout-structs</font></u> 
    and <strike><font color="#FF0000">POD-unions</font></strike> <u>
    <font color="#228822">standard-layout-unions</font></u> are described in 9.2. end note ]</td>
  </tr>
  <tr>
    <td width="76%"><i><b>5.2 7 Postfix expressions</b></i><p>When there is no 
    parameter for a given argument, the argument is passed in such a way that 
    the receiving function can obtain the value of the argument by invoking 
    va_arg (18.8). The lvalue-to-rvalue (4.1), array-to-pointer (4.2), and 
    function-to-pointer (4.3) standard conversions are performed on the argument 
    expression. After these conversions, if the argument does not have 
    arithmetic, enumeration, pointer, pointer to member, or class type, the 
    program is ill-formed. If the argument has a  
    <strike><font color="#FF0000">non-POD</font></strike> <font color="#228822">
    <u>non-trivial</u></font> class type (clause 9), 
    the behavior is undefined. If the argument has integral or enumeration type 
    that is subject to the integral promotions (4.5), or a floating point type 
    that is subject to the floating point promotion (4.6), the value of the 
    argument is converted to the promoted type before the call. These promotions 
    are referred to as the default argument promotions.</td>
  </tr>
  <tr>
    <td width="76%"><b><i><a name="5.3/16">5.3.4 16</a> New</i></b><p>A new-expression 
    that creates an object of type T initializes that object as follows:<br>
     If the new-initializer is omitted:<br>
    &nbsp;&nbsp;&nbsp;
     If T is a (possibly cv-qualified) <strike><font color="#FF0000">non-POD</font></strike> <font color="#228822">
    <u>non-trivial</u></font> class type (or array thereof), the object is default-initialized (8.5).
    If T is a const-qualified type, the underlying class type shall have a 
    user-declared default constructor.<br>
    &nbsp;&nbsp;&nbsp;
     Otherwise, the object created has indeterminate value. If T is a 
    const-qualified type, or a (possibly cv-qualified)  <strike><font color="#FF0000">POD</font></strike>
    <font color="#228822"><u>trivial</u></font> class type (or array 
    thereof) containing (directly or indirectly) a member of const-qualified 
    type, the program is ill-formed;<br>
     If the new-initializer is of the form (), the item is value-initialized 
    (8.5);<br>
     If the new-initializer is of the form (expression-list) and T is a class 
    type, the appropriate constructor is called, using expression-list as the 
    arguments (8.5);<br>
     If the new-initializer is of the form (expression-list) and T is an 
    arithmetic, enumeration, pointer, or pointer-to-member type and 
    expression-list comprises exactly one expression, then the object is 
    initialized to the (possibly converted) value of the expression (8.5);<br>
     Otherwise the new-expression is ill-formed.</td>
  </tr>
  <tr>
    <td width="76%"><i><b>5.9 7 Relational operators [expr.rel]</b></i><p>
    Pointers to objects or functions of the same type (after pointer 
    conversions) can be compared, with a result defined as follows: <br>
    ...<br>
     If two pointers point to non-static data members of the same object, or to 
    subobjects or array elements of such<br>
    members, recursively, the pointer to the later declared member compares 
    greater provided the two members <strike><font color="#FF0000">are<br>
    not separated by an access-specifier label (11.1)</font></strike> <u><font color="#228822">
    have the same access control (clause 11)</font></u> and provided their class 
    is not a union.<br>
    <br>
     If two pointers point to non-static data members of the same object
    <strike><font color="#FF0000">separated by an access-specifier label (11.1)</font></strike> <font color="#228822"> <u>
    with different access control (clause 11)</u> </font>the result is 
    unspecified.</p>
    <table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%">
      <tr>
        <td width="100%"><i>See<font color="#228822"> <a href="#Rationale">
        rationale</a></font></i></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width="76%"><i><b>5.19 4 Constant expressions</b></i><p>An address 
    constant expression is a pointer to an lvalue designating an object of 
    static storage duration, a string literal (2.13.4), or a function. The 
    pointer shall be created explicitly, using the unary &amp; operator, or 
    implicitly using a non-type template parameter of pointer type, or using an 
    expression of array (4.2) or function (4.3) type. The subscripting operator 
    [] and the class member access . and -&gt; operators, the &amp; and * unary 
    operators, and pointer casts (except dynamic_casts, 5.2.7) can be used in 
    the creation of an address constant expression, but the value of an object 
    shall not be accessed by the use of these operators. If the subscripting 
    operator is used, one of its operands shall be an integral constant 
    expression. An expression that designates the address of a subobject of a 
    <strike><font color="#FF0000">non-POD</font></strike> <font color="#228822">
    <u>non-trivial</u></font> class object (clause 9) is not an address constant expression 
    (12.7). Function calls shall not be used in an address constant expression, 
    even if the function is inline and has a reference return type.</td>
  </tr>
  <tr>
    <td width="76%"><i><b>5.19 5 Constant expressions</b></i><p>A reference 
    constant expression is an lvalue designating an object of static storage 
    duration, a non-type template parameter of reference type, or a function. 
    The subscripting operator [], the class member access . and -&gt; operators, 
    the &amp; and * unary operators, and reference casts (except those invoking 
    user-defined conversion functions (12.3.2) and except dynamic_casts (5.2.7)) 
    can be used in the creation of a reference constant expression, but the 
    value of an object shall not be accessed by the use of these operators. If 
    the subscripting operator is used, one of its operands shall be an integral 
    constant expression. An lvalue expression that designates a member or base 
    class of a <strike><font color="#FF0000">non-POD</font></strike> <font color="#228822">
    <u>non-trivial</u></font> class object (clause 9) is not a reference constant 
    expression (12.7). Function calls shall not be used in a reference constant 
    expression, even if the function is inline and has a reference return type.</td>
  </tr>
  <tr>
    <td width="76%"><b><i>6.7 3 Declaration statement</i></b><p>It is possible 
    to transfer into a block, but not in a way that bypasses declarations with 
    initialization. A program that jumps82) from a point where a local variable 
    with automatic storage duration is not in scope to a point where it is in 
    scope is ill-formed unless the variable has  <strike><font color="#FF0000">POD</font></strike>
    <font color="#228822"><u>trivial</u></font> type (3.9) and is declared 
    without an initializer (8.5).</td>
  </tr>
  <tr>
    <td width="76%"><b><i>6.8 4 Ambiguity resolution</i></b><p>The 
    zero-initialization (8.5) of all local objects with static storage duration 
    (3.7.1) is performed before any other initialization takes place. A local 
    object of  <strike><font color="#FF0000">POD</font></strike>
    <font color="#228822"><u>trivial</u></font> type (3.9) with static storage duration initialized with 
    constant-expressions is initialized before its block is first entered. An 
    implementation is permitted to perform early initialization of other local 
    objects with static storage duration under the same conditions that an 
    implementation is permitted to statically initialize an object with static 
    storage duration in namespace scope (3.6.2). Otherwise such an object is 
    initialized the first time control passes through its declaration; such an 
    object is considered initialized upon the completion of its initialization. 
    If the initialization exits by throwing an exception, the initialization is 
    not complete, so it will be tried again the next time control enters the 
    declaration. If control re-enters the declaration (recursively) while the 
    object is being initialized, the behavior is undefined.</td>
  </tr>
  <tr>
    <td width="76%"><b><i><a name="8.5/5">8.5 5</a> Initializers</i></b><blockquote>
      <p>To <i>default-initialize</i> an 
    object of type T means:<br>
     if T is a <strike><font color="#FF0000">non-POD</font></strike>
      <font color="#228822"><u>non-trivial</u></font> class type (clause 9), the default constructor for T is 
    called (and the initialization is ill-formed if T has no accessible default 
    constructor);<br>
     if T is an array type, each element is default-initialized;<br>
     otherwise, the object is zero-initialized.</blockquote>
    </td>
  </tr>
  <tr>
    <td width="76%"><b><i><a name="8.5/9">8.5 9</a> Initializers</i></b><p>If no initializer is 
    specified for an object, and the object is of (possibly cv-qualified)
    <strike><font color="#FF0000">non-POD</font></strike> <font color="#228822">
    <u>non-trivial</u></font> class type (or array thereof), the object shall be 
    default-initialized; if the object is of const-qualified type, the 
    underlying class type shall have a user-declared default constructor. 
    Otherwise, if no initializer is specified for a non-static object, the 
    object and its subobjects, if any, have an indeterminate initial value97); 
    if the object or any of its subobjects are of const-qualified type, the 
    program is ill-formed.</td>
  </tr>
  <tr>
    <td width="76%"><b><i>8.5 14 Initializers</i></b><p>When an aggregate with 
    static storage duration is initialized with a brace-enclosed 
    initializer-list, if all the member initializer expressions are constant 
    expressions, and the aggregate is a <font color="#FF0000"><strike>POD</strike></font> <font color="#228822">
    <u>trivial</u></font> type, the initialization shall be 
    done during the static phase of initialization (3.6.2); otherwise, it is 
    unspecified whether the initialization of members with constant expressions 
    takes place during the static phase or during the dynamic phase of 
    initialization.</td>
  </tr>
  <tr>
    <td width="76%"><b>8.5.1 <i>1 Aggregates</i></b><p>
    An <i>
    aggregate</i> 
    is an array or a class (clause 9) with no user-declared constructors (12.1), 
    no private or protected non-static data members (clause 11), no base classes
    <u><font color="#228822">with non-static data members</font></u> 
    (clause 10), and no virtual functions (10.3).<br>
&nbsp;<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%">
      <tr>
        <td width="100%"><i>Portland meeting: &quot;no user-declared constructors&quot; 
        wording unchanged at request of CWG.</i></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width="76%" valign="top"><b><i>9.2 12 Class members [<a name="class.mem">class.mem</a>]</i></b><p>
    Nonstatic data members of a (non-union) class <font color="#FF0000"><strike>declared without an 
    intervening access-specifier</strike></font> <u><font color="#228822">with 
    the same access control (clause 11)</font></u> are allocated so that later members have 
    higher addresses within a class object. The order of allocation of 
    non-static data members <font color="#FF0000"><strike>separated by an access-specifier</strike></font>
    <u><font color="#228822">with different access control</font></u> is 
    unspecified (11.1). Implementation alignment requirements might cause two 
    adjacent members not to be allocated immediately after each other; so might 
    requirements for space for managing virtual functions (10.3) and virtual 
    base classes (10.1).<br>
&nbsp;<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%">
      <tr>
        <td width="100%"><i>See <font color="#228822"><a href="#Rationale">
        rationale</a></font>.</i></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width="76%"><b><i>9.2 15-18 Class members [<a name="class.mem">class.mem</a>]</i></b><p>
    15 Two <font color="#FF0000"><strike>POD-struct</strike></font> <u>
    <font color="#228822">standard-layout-struct</font></u> (clause 9) types 
    are layout-compatible if they have the same number of non-static data 
    members, and corresponding non-static data members (in order) have 
    layout-compatible types (3.9).</p>
    <p>16 Two <font color="#FF0000"><strike>POD-union</strike></font> <u>
    <font color="#228822">standard-layout-union</font></u> (clause 9) types are layout-compatible if they have the 
    same number of non-static data members, and corresponding non-static data 
    members (in any order) have layout-compatible types (3.9).</p>
    <p>17 If a <font color="#FF0000"><strike>POD-union</strike></font> <u>
    <font color="#228822">standard-layout-union</font></u> contains two or more
    <font color="#FF0000"><strike>POD-structs</strike></font> <u>
    <font color="#228822">standard-layout-structs</font></u> that share a common 
    initial sequence, and if the <font color="#FF0000"><strike>POD-union</strike></font>
    <u><font color="#228822">standard-layout-union</font></u> object currently contains one of 
    these <font color="#FF0000"><strike>POD-structs</strike> </font>
    <font color="#228822"><u>standard-layout-structs</u>,</font> it is permitted to inspect the common initial part of any 
    of them. Two <font color="#FF0000"><strike>POD-structs</strike></font>
    <font color="#228822"><u>standard-layout-structs </u></font>share a common initial sequence if corresponding 
    members have layout-compatible types (and, for bit-fields, the same widths) 
    for a sequence of one or more initial members.</p>
    <p><a name="9.2-18">18</a> A pointer to a <font color="#FF0000"><strike>POD-struct</strike></font>
    <u><font color="#228822">standard-layout-struct</font></u> 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. [ Note: 
    There might therefore be unnamed padding within a <font color="#FF0000">
    <strike>POD-struct</strike></font> <u><font color="#228822">
    standard-layout-struct</font></u> object, but not 
    at its beginning, as necessary to achieve appropriate alignment. end note ]</td>
  </tr>
  <tr>
    <td width="76%"><b><i>9.5 1 Unions</i></b><p>In a union, at most one of the 
    data members can be active at any time, that is, the value of at most one of 
    the data members can be stored in a union at any time. [ Note: one special 
    guarantee is made in order to simplify the use of unions: If a 
    <font color="#FF0000"><strike>POD-union</strike></font> <u>
    <font color="#228822">standard-layout-union</font></u> contains several
    <font color="#FF0000"><strike>POD-structs</strike></font> <u>
    <font color="#228822">standard-layout-structs</font></u> that share a common 
    initial sequence (9.2), and if an object of this <font color="#FF0000">
    <strike>POD-union</strike></font> <u><font color="#228822">
    standard-layout-union</font></u> type contains one of the
    <font color="#FF0000"><strike>POD-structs</strike></font> <u>
    <font color="#228822">standard-layout-structs</font></u>, it is 
    permitted to inspect the common initial sequence of any of 
    <font color="#FF0000"><strike>POD-struct</strike></font> <u>
    <font color="#228822">standard-layout-struct</font></u> 
    members; see 9.2. end note ] The size of a union is sufficient to contain 
    the largest of its data members. Each data member is allocated as if it were 
    the sole member of a struct. A union can have member functions (including 
    constructors and destructors), but not virtual (10.3) functions. A union 
    shall not have base classes. A union shall not be used as a base class. An object of a class with a 
    non-trivial default constructor (12.1), a non-trivial copy constructor 
    (12.8), a non-trivial destructor (12.4), or a non-trivial copy assignment 
    operator (13.5.3, 12.8) cannot be a member of a union, nor can an 
    array of such objects. If a union contains a static data member, or a member 
    of reference type, the program is ill-formed.</td>
  </tr>
  <tr>
    <td width="76%"><i><b>11.1</b></i> <b><i>3 Access Specifiers</i></b><p>The 
    order of allocation of data members with <font color="#FF0000"><strike>separate access-specifier labels</strike></font>
    <u><font color="#228822">different access control</font></u> is 
    unspecified (9.2)<u><font color="#228822">, except as described in [class.mem]</font></u>.<br>
&nbsp;<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%">
      <tr>
        <td width="100%"><i>The &quot;</i>except as described in [class.mem]<font color="#228822">&quot;</font><i> 
        wording is a clarification to make it clearer that [class.mem] applies.</i></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width="76%"><b><i><a name="12.6.2/4">12.6.2 4</a> Initializing bases and members</i></b><p>If a 
    given non-static data member or base class is not named by a mem-initializer-id 
    (including the case where there is no mem-initializer-list because the 
    constructor has no ctor-initializer), then<br>
    <br>
     If the entity is a non-static data member of (possibly cv-qualified) class 
    type (or array thereof) or a base class, and the entity class is a <strike>
    <font color="#FF0000">non-POD</font></strike> <font color="#228822">
    <u>non-trivial</u></font> 
    class the entity is default-initialized (8.5). If the entity is a 
    non-static data member of a const-qualified type, the entity class shall 
    have a user-declared default constructor.<br>
    <br>
     Otherwise, the entity is not initialized. If the entity is of 
    const-qualified type or reference type, or of a (possibly cv-qualified)  <strike><font color="#FF0000">POD</font></strike>
    <font color="#228822"><u>trivial</u></font> 
    class type (or array thereof) containing (directly or indirectly) a member 
    of a const-qualified type, the program is ill-formed.<br>
    <br>
    After the call to a constructor for class X has completed, if a member of X 
    is neither specified in the constructors mem-initializers, nor 
    default-initialized, nor value-initialized, nor given a value during 
    execution of the body of the constructor, the member has indeterminate 
    value.</td>
  </tr>
  <tr>
    <td width="76%"><b><i><a name="12.7/1">12.7 1</a> Construction and destruction</i></b><p>
    For an object of <strike><font color="#FF0000">non-POD</font></strike> <font color="#228822">
    <u>non-trivial</u></font> class type (clause 9) before the constructor begins 
    execution and after the destructor&nbsp;finishes execution, referring to 
    any non-static member or base class of the object results in undefined 
    behavior. [ <i>Example:</i></p>
    <blockquote>
      <pre>struct X { int i; };                 
struct Y : X { <u><font color="#228822">X();</font></u> }; <u><font color="#228822">// non-trivial</font></u>                   
struct A { int a; };                 
struct B : public A { int j; Y y; <u><font color="#228822">B();</font></u> }; <u><font color="#228822">// non-trivial</font></u><span style="background-color: #FFFF00">
</span>
extern B bobj;
B* pb = &amp;bobj;         // OK
int* p1 = &amp;bobj.a;     // undefined, refers to base class member
int* p2 = &amp;bobj.y.i;   // undefined, refers to members member

A* pa = &amp;bobj;         // undefined, upcast to a base class type
B bobj;                // definition of bobj

extern X xobj;
int* p3 = &amp;xobj.i;     //OK, X is a <font color="#FF0000"><strike>POD</strike></font> <font color="#228822"><u>trivial</u></font> class
X xobj;</pre>
    </blockquote>
    </td>
  </tr>
  <tr>
    <td width="76%"><b><i>17.1.3 character container type</i></b><p>a class or a 
    type used to represent a character (17.1.2). It is used for one of the 
    template parameters of the string and iostream class templates. A character 
    container class shall be a POD (3.9) type.<br>
&nbsp;<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%">
      <tr>
        <td width="100%"><i>No change proposed; there is no known motivation for 
        any change.</i></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width="76%"><b><i>18.1 4 Types</i></b><p>The macro offsetof(type, 
    member-designator) accepts a restricted set of type arguments in this 
    International Standard. If type is not a <font color="#FF0000"><strike>POD structure or a POD union</strike></font>
    <font color="#228822"><u>standard-layout-struct or a standard-layout-union</u></font> 
    (clause 9), the results are undefined.189) The expression offsetof(type, 
    member-designator) is never type-dependent (14.6.2.2) and it is 
    value-dependent (14.6.2.3) if and only if type is dependent. The result of 
    applying the offsetof macro to a field that is a static data member or a 
    function member is undefined.</td>
  </tr>
  <tr>
    <td width="76%"><i><b>20.4 type traits</b></i><p>To 20.4.2, Header &lt;type_traits&gt; 
    synopsis [lib.meta.type.synop], type properties, add:</p>
    <blockquote>
      <pre><u><font color="#228822">template &lt;class T&gt; struct is_trivial;
template &lt;class T&gt; struct is_standard_layout;</font></u></pre>
    </blockquote>
    <p>To 20.4.5.3 Type properties [lib.meta.unary.prop], Type Property 
    Predicates table, add:<br>
&nbsp;<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%">
      <tr>
        <td width="33%" align="center"><b>Template</b></td>
        <td width="33%" align="center"><b>Condition</b></td>
        <td width="34%" align="center"><b>Preconditions</b></td>
      </tr>
      <tr>
        <td width="33%"><u><font color="#228822"><code>template &lt;class T&gt;<br>
        struct is_trivial;</code></font></u></td>
        <td width="33%"><u><font color="#228822"><code>T</code> is a trivial type ([basic.types])</font></u></td>
        <td width="34%"><u><font color="#228822"><code>T</code> shall be a complete type.</font></u></td>
      </tr>
      <tr>
        <td width="33%"><u><font color="#228822"><code>template &lt;class T&gt;<br>
        struct is_standard_layout;</code></font></u></td>
        <td width="33%"><u><font color="#228822"><code>T</code> is a standard-layout type ([basic.types])</font></u></td>
        <td width="34%"><u><font color="#228822"><code>T</code> shall be a complete type.</font></u></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width="76%"><i><b>21 1 Strings library</b></i><p>This clause describes 
    components for manipulating sequences of characters, where characters may 
    be of any POD (3.9) type. In this clause such types are called char-like 
    types, and objects of char-like types are called char-like objects or simply 
    characters.<br>
&nbsp;<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%">
      <tr>
        <td width="100%"><i>No change. Users expect <code>
    c_str()</code> and <code>data()</code> to return pointers to 
    POD types.</i></td>
      </tr>
    </table>
    </td>
  </tr>
  <tr>
    <td width="76%"><b><i>25.4 4 C library algorithms</i></b><p>The function 
    signature:<br>
    <br>
    <code>qsort(void *, size_t, size_t, int (*)(const void *, const void *));</code><br>
    <br>
    is replaced by the two declarations:<br>
    <br>
    <code>extern &quot;C&quot; void qsort(void* base , size_t nmemb , size_t size, int (*compar 
    )(const void*, const void*));</code><br>
    <br>
    <code>extern &quot;C++&quot; void qsort(void* base , size_t nmemb , size_t size, int (*compar 
    )(const void*, const void*)); </code> <br>
    <br>
    both of which have the same behavior as the original declaration. The 
    behavior is undefined unless the objects in the array pointed to by base are 
    of <strike><font color="#FF0000">POD</font></strike> <font color="#228822">
    <u>trivial</u></font> type.</td>
  </tr>
</table>

<h2><a name="Impact">Impact</a> on existing code</h2>

<p>The proposed changes will cause some existing non-POD's to become 
POD's. This may result in less optimization being performed. The problem can be 
eliminated by adding a user-defined do-nothing destructor.</p>

<p>Adding a user-defined do-nothing destructor to existing code 
    to leave POD-ness unchanged is simple enough that it could be done 
    programmatically. If a compiler vendor felt this was a serious concern for 
    their user-base, they might wish to provide such a program. Alternately, compilers may wish to issue warnings 
    during a transition period if the new 
rules change a non-POD into a  POD.</p>

<h2>Impact on existing <a name="ABI">ABI</a>'s</h2>

<p>Allowing standard-layout classes to have base classes, even restricted to 
base classes without non-static data members, forces compilers to implement the 
empty base optimization for standard-layout classes, and this could break a 
compiler's application binary interface (ABI). See <a href="#9.2-18">9.2/18</a> 
above.</p>

<p>Although this issue is still being investigated, it is believed not to be a 
concern for modern compilers, except in the case of multiple inheritance. Since 
multiple inheritance is not central to this proposal, allowing standard-layout 
classes or their bases to use multiple inheritance will be eliminated from the 
proposal if it proves contentious.</p>

<h2><a name="Interaction">Interaction</a> with other proposals</h2>

<p>See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1824.htm">
N1824</a>, Extending Aggregate Initialization. Whichever proposal is accepted 
first, the other will have to be reviewed, and possibly revised, accordingly.</p>

<p>See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2100.pdf">
N2100</a>, Initializer lists (Rev. 2). The authors of the Initializer lists 
proposal and the POD proposal are committed to working together to ensure the 
two proposals stay in sync.</p>

<p>See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#538">
Core issue 538</a>, Definition and usage of <i>structure</i>, <i>POD-struct</i>,
<i>POD-union</i>, and <i>POD class. </i>This issue, currently in review status, 
clarifies POD related terminology throughout the working paper. Since it makes 
changes to the same text modified by this proposal, care must be taken to ensure 
the two proposals do not diverge.</p>

<h2><a name="Revision-history">Revision history</a></h2>

<p><b>Revision 1 </b>-
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2102.html">
N2102</a></p>

<ul>
  <li>Review and refinement of all wording.</li>
  <li>Changed name from <i>byte-copyable-class</i> to <i>trivial-class</i>, to 
  reflect properties rather than uses.</li>
  <li>Added <i>standard-layout class</i> definition, in response to use cases 
  that were legitimately non-copyable, but otherwise met POD requirements.</li>
  <li>Changed proposed wording to be relative to issue 538's proposed wording.</li>
  <li>Made corrections based on discussions with Core and Evolution working 
  groups at the Portland committee meeting.</li>
  <li>Added section discussion <a href="#ABI">ABI issues</a>.</li>
</ul>

<p><b>Initial version </b>-
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2062.html">
N2062</a></p>

<h2><a name="Acknowledgements">Acknowledgements</a></h2>

<p>Matt Austern, Greg Colvin,  Alisdair Meredith, and Clark Nelson provided 
helpful comments during preparation of this proposal. Our cat Jane woke me up in 
the middle of the night, provoking this proposal as an alternative to counting 
sheep (or cats).</p>

<p>Revision 1 - Greg Colvin and Lawrence Crowl provided legitimately 
non-copyable use cases. Alberto Ganesh Barbati pointed out that the proposed 
resolution should be relative to the 538 proposed resolution. Martin Sebor 
pointed out the need for clarification of 11.1, p3. The EWG and CWG in Portland 
reviewed a draft of revision 1 and made many helpful comments and suggestions. 
Clark Nelson is facilitating progress through Core. A suggestion was made that 
trivial types be renamed inert POD's, or IPOD's. Mike Miller suggested that a
<code>pod_cast</code> operation be provided to ensure interoperability between 
POD's and IPOD's.</p>

<h2><a name="References">References</a></h2>

<p>N1824 Extending Aggregate Initialization, Alisdair Meredith,&nbsp;
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1824.htm">
www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1824.htm</a></p>

<p>Core issue 538.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#568">
www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#538</a>, Definition and 
usage of <i>structure</i>, <i>POD-struct</i>, <i>POD-union</i>, and <i>POD 
class.</i></p>

<p>Core issue 568.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#568">
www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#568</a>, Definition of POD 
is too strict.</p>

<hr>

<p>&nbsp;</p>

</body>

</html>
