<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
	"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-us">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>WG21/N2239: A finer-grained alternative to sequence points (revised)
</title>
<style type="text/css">
.deleted {
	text-decoration: line-through;
}
.inserted {
	text-decoration: underline;
}
</style>
</head>

<body>

<table summary="This table provides identifying information for this document.">
	<tr>
		<th>Doc. No.:</th>
		<td>WG21/N2239<br />
		J16/07-0099</td>
	</tr>
	<tr>
		<th>Date:</th>
		<td>2007-04-19</td>
	</tr>
	<tr>
		<th>Reply to:</th>
		<td>Clark Nelson</td>
	</tr>
	<tr>
		<th>Phone:</th>
		<td>+1-503-712-8433</td>
	</tr>
	<tr>
		<th>Email:</th>
		<td><a href="mailto:clark.nelson@intel.com">clark.nelson@intel.com</a></td>
	</tr>
</table>
<body>

<h1>A finer-grained alternative to sequence points (revised)</h1>
<p>This document contains the proposed working draft changes from N2171 which are 
not specific to parallel execution; i.e. just the reformulation of the &quot;sequence 
point&quot; rules. </p>
<h2><a id="rearranging">Rearranging the text of &quot;Program execution&quot;</a></h2>
<p>The changes proposed in N1944 were mainly in section 1.9 (Program execution) 
and various locations in clause 5 (Expressions), plus a couple of spots in clause 
12 (Special member functions). The &quot;undefined behavior&quot; rule, a key paragraph in 
the understanding of sequencing, which basically describes what may be called an 
&quot;intra-thread data race&quot;, is currently in 5p4, which is widely separated from the 
bulk of the discussion of the principles of sequencing in 1.9. Furthermore, it would 
seem logical to describe concurrency &#8212; and particularly inter-thread data races 
&#8212; in a new section building on and immediately following 1.9. Therefore we propose 
to move the &quot;undefined behavior&quot; rule from 5p4 to 1.9.</p>
<p>Within 1.9 with the changes proposed in N1944, the bulk of the discussion of 
sequencing is in p15-16. Paragraph 8, which currently contains the &quot;no overlap&quot; 
rule for function execution, should be merged into p16, which discusses many other 
sequencing constraints on function calls. And if, as proposed, the references to 
sequence points and evaluation are removed from p11 (the &quot;least requirements&quot;), 
then the definitions in p7 are not needed until p15; moving paragraph 7 down would 
result in a more cohesive presentation.</p>
<p>Finally, it could be argued that cohesiveness would be increased still further 
by moving the discussion of reassociation (concerning implications of the &quot;as-if&quot; 
rule) to immediately follow the &quot;least requirements&quot; (which is basically the normative 
statement of the &quot;as-if&quot; rule), instead of showing up in the middle of the discussion 
of expressions and sequencing.</p>
<p>This table shows the proposed shifting of content, assuming regular paragraph 
(re-)numbering. The letters in the central columns are just tags, intended to illustrate 
how text moves around (in lieu of arrows): the tag stays with the content.</p>
<table>
	<tr>
		<th>Paragraph number</th>
		<th>Old content</th>
		<th colspan="2"></th>
		<th>New content</th>
	</tr>
	<tr>
		<td>1.9p7</td>
		<td>Definitions of &quot;side effect&quot;, &quot;sequence point&quot;</td>
		<td>A</td>
		<td>C</td>
		<td>Effect of asynchronous signal</td>
	</tr>
	<tr>
		<td>1.9p8</td>
		<td>&quot;No overlap&quot; rule for function execution</td>
		<td>B</td>
		<td>C</td>
		<td>Allocation of automatic objects</td>
	</tr>
	<tr>
		<td>1.9p9</td>
		<td>Effect of asynchronous signal</td>
		<td>C</td>
		<td>C</td>
		<td>The &quot;least requirements&quot;</td>
	</tr>
	<tr>
		<td>1.9p10</td>
		<td>Allocation of automatic objects</td>
		<td>C</td>
		<td>E</td>
		<td>Note concerning reassociation</td>
	</tr>
	<tr>
		<td>1.9p11</td>
		<td>The &quot;least requirements&quot;</td>
		<td>C</td>
		<td>D</td>
		<td>Definition of &quot;full-expression&quot;</td>
	</tr>
	<tr>
		<td>1.9p12</td>
		<td>Definition of &quot;full-expression&quot;</td>
		<td>D</td>
		<td>D</td>
		<td>Note concerning default arguments</td>
	</tr>
	<tr>
		<td>1.9p13</td>
		<td>Note concerning default arguments</td>
		<td>D</td>
		<td>A</td>
		<td>Definition of &quot;side effect&quot;, &quot;evaluation&quot;</td>
	</tr>
	<tr>
		<td>1.9p14</td>
		<td>Note concerning reassociation</td>
		<td>E</td>
		<td>[new]</td>
		<td>Definition of &quot;sequenced before&quot;</td>
	</tr>
	<tr>
		<td>1.9p15</td>
		<td>Sequencing between full-expressions</td>
		<td>F</td>
		<td>F</td>
		<td>Sequencing between full-expressions</td>
	</tr>
	<tr>
		<td>1.9p16</td>
		<td>Sequencing constraints on function calls</td>
		<td>G</td>
		<td>5p4</td>
		<td>The &quot;undefined behavior&quot; rule</td>
	</tr>
	<tr>
		<td>1.9p17</td>
		<td>Operators that impose a sequence point</td>
		<td>[delete]</td>
		<td>G+B</td>
		<td>Sequencing constraints on function calls, including the &quot;no overlap&quot; 
		rule</td>
	</tr>
</table>
<h2><a id="execution">The text proposed for &quot;Program execution&quot;</a></h2>
<p>So here is the proposed reading of section 1.9, beginning with p6 (just for the 
sake of context). Each paragraph is introduced with its proposed paragraph number, 
and an explanation of its source. Text from the current working draft to be replaced 
or deleted is <span class="deleted">stricken through</span>. Replacement or added 
text is <span class="inserted">underlined</span>. Footnotes are presented here in 
the same style as examples and notes. If the introductory paragraphs, editorial 
notes and stricken text were deleted, the result would be a longish block of consecutive 
paragraphs, as proposed for the standard.</p>
<p>1.9p6 (unchanged):</p>
<blockquote>
	<p>The observable behavior of the abstract machine is its sequence of reads 
	and writes to <code>volatile</code> data and calls to library I/O functions. 
	An implementation can offer additional library I/O functions as an extension. 
	[ <em>Footnote:</em> Implementations that do so should treat calls to those 
	functions as &quot;observable behavior&quot; as well. &#8212;<em>end footnote</em> ]</p>
</blockquote>
<p><strong>Editorial note:</strong> This definition of observable behavior is not 
clearly consistent with the &quot;least requirements&quot; described in the proposed 1.9p9 
below (and is arguably incorrect, especially for multithreaded programs). Core issue 
612 has been opened to consider this inconsistency, and any corrections necessary 
for multithreading will be drafted in accordance with its resolution.</p>
<p>1.9p7 (unchanged from the current p9, except for the addition of an omitted word):</p>
<blockquote>
	<p>When the processing of the abstract machine is interrupted by receipt of 
	a signal, the values of objects with type other than <code>volatile std::sig_atomic_t</code> 
	are unspecified, and the value of any object not of <span class="inserted">type</span>
	<code>volatile std::sig_atomic_t</code> that is modified by the handler becomes 
	undefined.</p>
</blockquote>
<p>1.9p8 (unchanged from the current p10):</p>
<blockquote>
	<p>An instance of each object with automatic storage duration (3.7.2) is associated 
	with each entry into its block. Such an object exists and retains its last-stored 
	value during the execution of the block and while the block is suspended (by 
	a call of a function or receipt of a signal).</p>
</blockquote>
<p>1.9p9 (original text from p11):</p>
<blockquote>
	<p>The least requirements on a conforming implementation are:</p>
	<ul>
		<li><span class="deleted">At sequence points, volatile objects are stable 
		in the sense that previous evaluations are complete and subsequent evaluations 
		have not yet occurred.</span> <span class="inserted">Accesses to volatile 
		objects are evaluated strictly according to the rules of the abstract machine.</span></li>
		<li>At program termination, all data written into files shall be identical 
		to one of the possible results that execution of the program according to 
		the abstract semantics would have produced.</li>
		<li>The input and output dynamics of interactive devices shall take place 
		in such a fashion that prompting messages actually appear prior to a program 
		waiting for input. What constitutes an interactive device is implementation-defined.</li>
	</ul>
	<p>[ <em>Note:</em> more stringent correspondences between abstract and actual 
	semantics may be defined by each implementation. &#8212;<em>end note</em> ]</p>
</blockquote>
<p>1.9p10 (unchanged from p14):</p>
<blockquote>
	<p>[ <em>Note:</em> operators can be regrouped according to the usual mathematical 
	rules only where the operators really are associative or commutative.<sup>11)</sup> 
	For example, in the following fragment</p>
	<blockquote>
		<p><em>[unchanged text omitted]</em></p>
	</blockquote>
	<p>However on a machine in which overflows do not produce an exception and in 
	which the results of overflows are reversible, the above expression statement 
	can be rewritten by the implementation in any of the above ways because the 
	same result will occur. &#8212;<em>end note</em> ]</p>
</blockquote>
<p>1.9p11 (original text from p12):</p>
<blockquote>
	<p>A <dfn>full-expression</dfn> is an expression that is not a subexpression 
	of another expression. If a language construct is defined to produce an implicit 
	call of a function, a use of the language construct is considered to be an expression 
	for the purposes of this definition. <span class="inserted">A call to a destructor 
	generated at the end of the lifetime of an object other than a temporary object 
	is an implicit full-expression.</span> Conversions applied to the result of 
	an expression in order to satisfy the requirements of the language construct 
	in which the expression appears are also considered to be part of the full-expression. 
	[ <em>Example:</em></p>
	<blockquote>
		<p><em>[unchanged example omitted]</em></p>
	</blockquote>
</blockquote>
<p>1.9p12 (unchanged from p13):</p>
<blockquote>
	<p>[ <em>Note:</em> the evaluation of a full-expression can include the evaluation 
	of subexpressions that are not lexically part of the full-expression. For example, 
	subexpressions involved in evaluating default argument expressions (8.3.6) are 
	considered to be created in the expression that calls the function, not the 
	expression that defines the default argument. &#8212;<em>end note</em> ]</p>
</blockquote>
<p>1.9p13 (original text from p7):</p>
<blockquote>
	<p>Accessing an object designated by a <code>volatile</code> lvalue (3.10), 
	modifying an object, calling a library I/O function, or calling a function that 
	does any of those operations are all <dfn>side effects</dfn>, which are changes 
	in the state of the execution environment. <span class="deleted">Evaluation 
	of an expression might produce side effects.</span> <span class="inserted">
	<dfn>Evaluation</dfn> of an expression (or sub-expression) in general includes 
	both value computations (including determining the identity of an object for 
	lvalue evaluation, and fetching a value previously assigned to an object for 
	rvalue evaluation) and initiation of side effects.</span>
	<span class="deleted">At certain specified points in the execution sequence 
	called <dfn>sequence points</dfn>, all side effects of previous evaluations 
	shall be complete and no side effects of subsequent evaluations shall have taken 
	place. [ <em>Footnote:</em></span> Note <span class="deleted">that some aspects 
	of sequencing in the abstract machine are unspecified; the preceding restriction 
	upon side effects applies to that particular execution sequence in which the 
	actual code is generated. Also note</span> that when a call to a library I/O 
	function returns, <span class="inserted">or an access to a <code>volatile</code> 
	object is evaluated,</span> the side effect is considered complete, even though 
	some external actions implied by <span class="inserted">either</span> the call (such as the I/O itself)
	<span class="inserted">or the <code>volatile</code> access</span> may not have 
	completed yet. <span class="deleted">&#8212;<em>end footnote</em> ]</span></p>
</blockquote>
<p>Note that what was a footnote has been modified and incorporated into the normative text.</p>
<p><a id="s1.9p14">1.9p14 (new paragraph):</a></p>
<blockquote class="inserted">
	<p>&quot;<dfn>Sequenced before</dfn>&quot; is an asymmetric, transitive, pair-wise relation 
	between evaluations executed by a single thread, which induces a partial order 
	among those evaluations. Given any two evaluations <var>A</var> and <var>B</var>, 
	if <var>A</var> is sequenced before <var>B</var>, then the execution of <var>
	A</var> shall precede the execution of <var>B</var>. If <var>A</var> is not 
	sequenced before <var>B</var> and <var>B</var> is not sequenced before <var>
	A</var>, then <var>A</var> and <var>B</var> are <dfn>unsequenced</dfn>. [
	<em>Note:</em> The execution of unsequenced evaluations can overlap. &#8212;<em>end 
	note</em> ] Evaluations <var>A</var> and <var>B</var> are <dfn>indeterminately 
	sequenced</dfn> when either <var>A</var> is sequenced before <var>B</var>, or
	<var>B</var> is sequenced before <var>A</var>, but it is unspecified which. 
	[ <em>Note:</em> Indeterminately sequenced evaluations shall not overlap, but 
	either could be executed first. &#8212;<em>end note</em> ]</p>
</blockquote>
<p>1.9p15 (original text from p15):</p>
<blockquote>
	<p><span class="deleted">There is a sequence point at the completion of evaluation 
	of each full-expression.</span> <span class="inserted">Every value computation 
	and side effect associated with a full-expression is sequenced before every 
	value computation and side effect associated with the next full-expression to 
	be evaluated.</span> [ <em>Footnote:</em> As specified in 12.2,
	<span class="deleted">after the &quot;end-of-full-expression&quot; sequence point</span>
	<span class="inserted">after a full-expression is evaluated</span>, a sequence 
	of zero or more invocations of destructor functions for temporary objects takes 
	place, usually in reverse order of the construction of each temporary object. 
	&#8212;<em>end footnote</em> ]</p>
</blockquote>
<p><a id="s1.9p16">1.9p16 (original text from clause 5 paragraph 4):</a></p>
<blockquote>
	<p>Except where noted, <span class="deleted">the order of evaluation</span>
	<span class="inserted">evaluations</span> of operands of individual operators<span class="inserted">,</span> 
	and <span class="inserted">of</span> subexpressions of individual expressions<span class="deleted">, 
	and the order in which side effects take place, is unspecified</span>
	<span class="inserted">are unsequenced</span>. [ <em>Footnote:</em> The precedence 
	of operators is not directly specified, but it can be derived from the syntax. 
	&#8212;<em>end footnote</em> ] <span class="inserted">[ <em>Note:</em> In an expression 
	that is evaluated more than once during the execution of a program, unsequenced 
	and indeterminately sequenced evaluations of its subexpressions need not be 
	performed consistently in different evaluations. &#8212;<em>end note</em> ] The value 
	computations of the operands of an operator are sequenced before the value computation 
	of the result of the operator.</span> <span class="deleted">Between the previous 
	and next sequence point a scalar object shall have its stored value modified 
	at most once by the evaluation of an expression. Furthermore, the prior value 
	shall be accessed only to determine the value to be stored. The requirements 
	of this paragraph shall be met for each allowable ordering of the subexpressions 
	of a full expression; otherwise the behavior is undefined.</span>
	<span class="inserted">If a side effect on a scalar object is unsequenced relative 
	to either a different side effect on the same scalar object, or a value computation 
	using the value of the same scalar object, the behavior is undefined.</span> 
	[ <em>Example:</em></p>
	<blockquote>
		<pre>i = v[i++];       <em>// the behavior is undefined</em>
<!--      -->i = 7, i++, i++;  <em>//</em> i <em>becomes</em> 9
<!--      -->i = ++i + 1;      <em>// the behavior is undefined</em>
<!--      -->i = i + 1;        <em>// the value of</em> i <em>is incremented</em></pre>
	</blockquote>
	<p>&#8212;<em>end example</em> ]</p>
</blockquote>
<p><strong>Editorial note:</strong> It has been pointed out that, under this proposed 
wording, unsequenced read accesses to a single volatile object (clearly) entail 
undefined behavior, which was not clearly the case with the previous wording. The 
key difference is that the new words refer to a &quot;side effect&quot;, which definitely 
includes reading a volatile object, whereas the previous words referred to modifying 
an object &quot;by the evaluation of an expression&quot;, which is ambiguous with respect 
to reading a volatile object &#8212; since such an action is a side effect, modification 
of the object accessed (or of some other volatile object) is possible but not inevitable.</p>
<p><a id="s1.9p17">1.9p17 (original text is p16 with p8 inserted):</a></p>
<blockquote>
	<p></p>
	<p>When calling a function (whether or not the function is inline),
	<span class="deleted">there is a sequence point after the evaluation of all 
	function arguments (if any) which takes place</span> <span class="inserted">
	every value computation and side effect associated with any argument expression, 
	or with the postfix expression designating the called function, is sequenced</span> 
	before execution of <span class="deleted">any expressions or statements</span>
	<span class="inserted">every expression or statement</span> in the
	<span class="inserted">body of the called</span> function
	<span class="deleted">body</span>. <span class="inserted">[ <em>Note:</em> Value 
	computations and side effects associated with different argument expressions 
	are unsequenced. &#8212;<em>end note</em> ]</span> <span class="deleted">There is 
	also a sequence point after the copying of a returned value and before the execution 
	of any expressions outside the function. [ <em>Footnote:</em> The sequence point 
	at the function return is not explicitly specified in ISO C, and can be considered 
	redundant with sequence points at full-expressions, but the extra clarity is 
	important in C++. In C++, there are more ways in which a called function can 
	terminate its execution, such as the throw of an exception. &#8212;<em>end footnote</em> 
	]</span> <span class="deleted">Once the execution of a function begins, no expressions 
	from the calling function are evaluated until execution of the called function 
	has completed.</span> <span class="inserted">Every evaluation in the calling 
	function (including other function calls) that is not otherwise specifically 
	sequenced before or after the execution of the body of the called function is 
	indeterminately sequenced with respect to the execution of the called function.</span> 
	[ <em>Footnote:</em> In other words, function executions do not &quot;interleave&quot; 
	with each other. &#8212;<em>end footnote</em> ] Several contexts in C++ cause evaluation 
	of a function call, even though no corresponding function call syntax appears 
	in the translation unit. [ <em>Example:</em> evaluation of a new expression 
	invokes one or more allocation and constructor functions; see 5.3.4. For another 
	example, invocation of a conversion function (12.3.2) can arise in contexts 
	in which no function call syntax appears. &#8212;<em>end example</em> ] The
	<span class="deleted">sequence points at function-entry and function-exit</span>
	<span class="inserted">sequencing constraints on the execution of the called 
	function</span> (as described above) are features of the function calls as evaluated, 
	whatever the syntax of the expression that calls the function might be.</p>
</blockquote>
<p>Deleted as redundant with descriptions of operators (original text from p17):</p>
<blockquote>
	<p><span class="deleted">In the evaluation of each of the expressions</span></p>
	<blockquote>
		<pre><span class="deleted">a &amp;&amp; b
a || b
a ? b : c
a , b</span></pre>
	</blockquote>
	<p><span class="deleted">using the built-in meaning of the operators in these 
	expressions (5.14, 5.15, 5.16, 5.18), there is a sequence point after the evaluation 
	of the first expression. [ <em>Footnote:</em> The operators indicated in this 
	paragraph are the built-in operators, as described in clause 5. When one of 
	these operators is overloaded (clause 13) in a valid context, thus designating 
	a user-defined operator function, the expression designates a function invocation, 
	and the operands form an argument list, without an implied sequence point between 
	them. &#8212;<em>end footnote</em> ]</span></p>
</blockquote>
<h2><a id="operators">Sequencing for specific operators</a></h2>
<p>It seems appropriate to remind the reader, at this point in the paper, that the 
proposal is to move 5p4 from its current location.</p>
<p>5.2.2p8 (function call):</p>
<blockquote>
	<p><span class="inserted">[ <em>Note:</em></span> <span class="deleted">The 
	order of evaluation of arguments is unspecified.</span>
	<span class="inserted">The evaluations of the postfix expression and of the 
	argument expressions are all unsequenced relative to one another</span>. All 
	side effects of argument expression evaluations <span class="deleted">take effect</span>
	<span class="inserted">are sequenced</span> before the function is entered<span class="inserted">; 
	see ([intro.execution]=1.9).</span> <span class="deleted">The order of evaluation 
	of the postfix expression and the argument expression list is unspecified.</span>
	<span class="inserted">&#8212;<em>end note</em> ]</span></p>
</blockquote>
<p><a id="s5.2.6p1">5.2.6p1</a> (post-increment):</p>
<blockquote>
	<p>The value <span class="deleted">obtained by applying</span>
	<span class="inserted">of</span> a postfix <code>++</code>
	<span class="inserted">expression</span> is the value <span class="deleted">
	that the</span> <span class="inserted">of its</span> operand
	<span class="deleted">had before applying the operator</span>. [ <em>Note:</em> 
	the value obtained is a copy of the original value &#8212;<em>end note</em> ] The 
	operand shall be a modifiable lvalue. The type of the operand shall be an arithmetic 
	type or a pointer to a complete object type. <span class="deleted">After the 
	result is noted, the</span> <span class="inserted">The</span> value of the
	<span class="inserted">operand</span> object is modified by adding <code>1</code> 
	to it, unless the object is of type <code>bool</code>, in which case it is set 
	to <code>true</code>. [ <em>Note:</em> this use is deprecated, see Annex D. 
	&#8212;<em>end note</em> ] <span class="inserted">The value computation of the
	<code>++</code> expression is sequenced before the modification of the operand 
	object. With respect to an indeterminately-sequenced function call, the operation 
	of postfix <code>++</code> is a single evaluation. [ <em>Note:</em> Therefore, 
	a function call shall not intervene between the lvalue-to-rvalue conversion 
	and the side effect associated with any single postfix <code>++</code> operator. 
	&#8212;<em>end note</em> ]</span> The result is an rvalue. The type of the result 
	is the cv-unqualified version of the type of the operand. See also 5.7 and 5.17.</p>
</blockquote>
<p>5.14p2 (logical AND operator), and also 5.15p2 (logical OR operator):</p>
<blockquote>
	<p>The result is a <code>bool</code>. <span class="deleted">All side effects 
	of the first expression except for destruction of temporaries (12.2) happen 
	before the second expression is evaluated.</span> <span class="inserted">If 
	the second expression is evaluated, every value computation and side effect 
	associated with the first expression is sequenced before every value computation 
	and side effect associated with the second expression.</span></p>
</blockquote>
<p>5.16p1 (conditional operator):</p>
<blockquote>
	<p>Conditional expressions group right-to-left. The first expression is implicitly 
	converted to <code>bool</code> (clause 4). It is evaluated and if it is
	<code>true</code>, the result of the conditional expression is the value of 
	the second expression, otherwise that of the third expression.
	<span class="deleted">All side effects of the first expression except for destruction 
	of temporaries (12.2) happen before the second or third expression is evaluated.</span> 
	Only one of the second and third expressions is evaluated.
	<span class="inserted">Every value computation and side effect associated with 
	the first expression is sequenced before every value computation and side effect 
	associated with the second or third expression.</span></p>
</blockquote>
<p><a id="s5.17p1">5.17p1</a> (assignment and compound assignment operators):</p>
<blockquote>
	<p>The assignment operator (<code>=</code>) and the compound assignment operators 
	all group right-to-left. All require a modifiable lvalue as their left operand 
	and return <span class="deleted">an lvalue with the type and value of the left 
	operand after the assignment has taken place</span> <span class="inserted">an 
	lvalue referring to the left operand</span>. The result in all cases is a bit-field 
	if the left operand is a bit-field. <span class="inserted">In all cases, the 
	assignment is sequenced after the value computation of the right and left operands, 
	and before the value computation of the assignment expression. With respect 
	to an indeterminately-sequenced function call, the operation of a compound assignment 
	is a single evaluation. [ <em>Note:</em> Therefore, a function call shall not 
	intervene between the lvalue-to-rvalue conversion and the side effect associated 
	with any single compound assignment operator. &#8212;<em>end note</em> ]</span></p>
</blockquote>
<p>5.18p1 (comma operator):</p>
<blockquote>
	<p>A pair of expressions separated by a comma is evaluated left-to-right and 
	the value of the left expression is discarded. The lvalue-to-rvalue (4.1), array-to-pointer 
	(4.2), and function-to-pointer (4.3) standard conversions are not applied to 
	the left expression. <span class="deleted">All side effects (1.9) of the left 
	expression, except for the destruction of temporaries (12.2), are performed 
	before the evaluation of the right expression.</span> <span class="inserted">
	Every value computation and side effect associated with the left expression 
	is sequenced before every value computation and side effect associated with 
	the right expression.</span> The type and value of the result are the type and 
	value of the right operand; the result is an lvalue if its right operand is 
	an lvalue, and is a bit-field if its right operand is an lvalue and a bit-field.</p>
</blockquote>
<h2><a id="temporaries">Sequencing for destruction of temporaries</a></h2>
<p>12.2p3:</p>
<blockquote>
	<p>When an implementation introduces a temporary object of a class that has 
	a non-trivial constructor (12.1, 12.8), it shall ensure that a constructor is 
	called for the temporary object. Similarly, the destructor shall be called for 
	a temporary with a non-trivial destructor (12.4). Temporary objects are destroyed 
	as the last step in evaluating the full-expression (1.9) that (lexically) contains 
	the point where they were created. This is true even if that evaluation ends 
	in throwing an exception. <span class="inserted">The value computations and 
	side effects of destroying a temporary object are associated only with the full-expression, 
	not with any specific subexpression.</span></p>
</blockquote>
<p>12.2p4:</p>
<blockquote>
	<p>There are two contexts in which temporaries are destroyed at a different 
	point than the end of the full-expression. The first context is when a default 
	constructor is called to initialize an element of an array. If the constructor 
	has one or more default arguments, <span class="deleted">any temporaries</span>
	<span class="inserted">the destruction of every temporary</span> created in
	<span class="deleted">the</span> <span class="inserted">a</span> default argument
	<span class="deleted">expressions are destroyed immediately after return from 
	the constructor</span> <span class="inserted">expression is sequenced before 
	the construction of the next array element, if any</span>.</p>
</blockquote>
<p>12.2p5:</p>
<blockquote>
	<p>The second context is when a reference is bound to a temporary. The temporary 
	to which the reference is bound or the temporary that is the complete object 
	of a subobject to which the reference is bound persists for the lifetime of 
	the reference except as specified below. A temporary bound to a reference member 
	in a constructor&#8217;s ctor-initializer (12.6.2) persists until the constructor 
	exits. A temporary bound to a reference parameter in a function call (5.2.2) 
	persists until the completion of the full expression containing the call. A 
	temporary bound to the returned value in a function return statement (6.6.3) 
	persists until the function exits. <span class="deleted">In all these cases, 
	the temporaries created during the evaluation of the expression initializing 
	the reference, except the temporary to which the reference is bound, are destroyed 
	at the end of the full-expression in which they are created and in the reverse 
	order of the completion of their construction.</span> <span class="inserted">
	The destruction of a temporary whose lifetime is not extended by being bound 
	to a reference is sequenced before the destruction of every temporary which 
	is constructed earlier in the same full-expression.</span> If the lifetime of 
	two or more temporaries to which references are bound ends at the same point, 
	these temporaries are destroyed at that point in the reverse order of the completion 
	of their construction. In addition, the destruction of temporaries bound to 
	references shall take into account the ordering of destruction of objects with 
	static or automatic storage duration (3.7.1, 3.7.2); that is, if <code>obj1</code> 
	is an object with the same storage duration as the temporary and created before 
	the temporary is created the temporary shall be destroyed before <code>obj1</code> 
	is destroyed; if obj2 is an object with the same storage duration as the temporary 
	and created after the temporary is created the temporary shall be destroyed 
	after obj2 is destroyed. [ Example:</p>
</blockquote>
<h2><a id="miscellaneous">Fixes for miscellaneous sequencing issues</a></h2>
<p>3.6.2p1 (initialization of non-local objects):</p>
<blockquote>
	<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 POD type with static storage duration can be initialized 
	with a constant expression (5.19); this is called <dfn>constant initialization</dfn>. 
	Together, zero-initialization and constant initialization are called <dfn>static 
	initialization</dfn>; all other initialization is <dfn>dynamic initialization</dfn>. 
	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. <span class="inserted">An unordered initialization is indeterminately 
	sequenced with respect to every other dynamic initialization.</span> [ <em>Note:</em> 
	8.5.1 describes the order in which aggregate members are initialized. The initialization 
	of local static objects is described in 6.7. &#8212;<em>end note</em> ]</p>
</blockquote>
<p>8.5.1p17 (aggregate initialization); new paragraph:</p>
<blockquote>
	<p><span class="inserted">The full-expressions in an <var>initializer-clause</var> 
	are evaluated in the order in which they appear.</span></p>
</blockquote>
<p>12.6.2p3 (mem-initializers):</p>
<blockquote>
	<p>The <var>expression-list</var> in a <var>mem-initializer</var> is used to 
	initialize the base class or non-static data member subobject denoted by the
	<var>mem-initializer-id</var>. The semantics of a <var>mem-initializer</var> 
	are as follows:</p>
	<ul>
		<li>if the <var>expression-list</var> of the <var>mem-initializer</var> 
		is omitted, the base class or member subobject is value-initialized (see 
		8.5);</li>
		<li>otherwise, the subobject indicated by <var>mem-initializer-id</var> 
		is direct-initialized using <var>expression-list</var> as the <var>initializer</var> 
		(see 8.5).</li>
	</ul>
	<blockquote>
		<p><em>[unchanged example omitted]</em></p>
	</blockquote>
	<p><span class="deleted">There is a sequence point (1.9) after the initialization 
	of each base and member.</span> <span class="inserted">The initialization of 
	each base and member constitutes a full-expression.</span>
	<span class="deleted">The <var>expression-list</var> of</span>
	<span class="inserted">Any expression in</span> a <var>mem-initializer</var> 
	is evaluated as part of the <span class="deleted">initialization of the corresponding 
	base or member</span> <span class="inserted">full-expression that performs the 
	initialization</span>.</p>
</blockquote>
<p>14.2 (template arguments):</p>
<blockquote>
	<dl>
		<dt><var>template-argument:</var></dt>
		<dd><var><span class="deleted">assignment-expression</span>
		<span class="inserted">constant-expression</span></var></dd>
		<dd><var>type-id</var></dd>
		<dd><var>id-expression</var></dd>
	</dl>
</blockquote>

</body>

</body>

</html>
