0. 什么是副作用(side effects)
Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment.
Accessing an object designated by a volatile lvalue, modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment.
|
特别的,C99和C++2003都指出,no effect的expression允许不被执行
An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).
1. 什么是序列点(sequence points)
C99和C++2003对序列点的定义相同
At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.
中文表述为,序列点是一些被特别规定的位置,要求在该位置前的evaluations所包含的一切副作用在此处均已完成,而在该位置之后的evaluations所包含的任何副作用都还没有开始
例如C/C++都规定完整表达式(full-expression)后有一个序列点
|
上面的代码中i = 0以及j = i都是一个完整表达式,;说明了表达式的结束,因此在;处有一个序列点,按照序列点的定义,要求在i = 0之后j = i之前的那个序列点上对i = 0的求值以及副作用全部结束(0被写入i中),而j = i的任何副作用都还没有开始。由于j = i的副作用是把i的值赋给j,而i = 0的副作用是把i赋值为0,如果i = 0的副作用发生在j = i之后,就会导致赋值后j的值是i的旧值,这显然是不对的
由序列点以及副作用的定义很容易看出,在一个序列点上,所有可能影响程序状态的动作均已完成,那这样能否推断出在一个序列点上一个程序的状态应该是确定的呢?!答案是不一定,这取决于我们代码的写法。但是,如果在一个序列点上程序的状态不能被确定,那么标准规定这样的程序是undefined behavior,稍后会解释这个问题
2. 表达式求值(evaluation of expressions)与副作用发生的相互顺序
C99和C++2003都规定
Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified.
也就是说,C/C++都指出一般情况下在表达式求值过程中的操作数求值顺序以及副作用发生顺序是未说明的(unspecified)。为什么C/C++不详细定义这些顺序呢?原因是因为C/C++都是极端追求效率的语言,不规定这些顺序,是为了允许编译器有更大的优化余地,例如
|
|
编译器可以先计算(i++) + (j++) + (k++)的值,然后再对i、j、k各自加1,最后将i、j、k、x写回内存,这比每次完整的执行完++语义效率要高
3. 序列点对副作用的限制
C99和C++2003都有类似的如下规定
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.
也就是说,在相邻的两个序列点之间,一个对象只允许被修改一次,而且如果一个对象被修改则在这两个序列点之间对该变量的读取的唯一目的只能是为了确定该对象的新值(例如i++,需要先读取i的值以确定i的新值是旧值+1)。特别的,标准要求任意可能的执行顺序都必须满足该条件,否则代码将是undefined behavior
之所以序列点会对副作用有如此的限制,就是因为C/C++标准没有规定子表达式求值以及副作用发生之间的顺序,例如
|
前面我提到在一个序列点上程序的状态不一定是确定的,原因就在于相邻的两个序列点之间可能会发生多个副作用,这些副作用的发生顺序是未指定的,如果多于一个的副作用用于修改同一个对象,例如示例代码i = ++i + 1;,则程序的结果是依赖于副作用发生顺序的;另外,如果某个表达式既修改了某个对象又需要读取该对象的值,且读取对象的值并不用于确定对象新值,则读取和修改两个动作的先后顺序也会导致程序的状态不能唯一确定
所幸的是,“在相邻的两个序列点之间,一个对象只允许被修改一次,而且如果一个对象被修改则在这两个序列点之间只能为了确定该对象的新值而读一次”这一强制规定保证了符合要求的程序在任何一个序列点位置上其状态都可以确定下来
注,由于对于UDT类型存在operator重载,函数语义会提供新的序列点,因此某些对于built-in类型是undefined behavior的表达式对于UDT确可能是良好定义的,例如
|
由此可见,常见的问题如printf("%d, %d", i++, i++)这种写法是错误的,这类问题作为笔试题或者面试题是没有任何意义的
类似的问题同样发生在cout << i++ << i++这种写法上,如果overload resolution选择成员函数operator<<,则等价于(cout.operator<<(i++)).operator<<(i++),否则等价于operator<<(operator<<(cout, i++), i++),如果i是built-in类型对象,这种写法跟foo(foo(0, i++), i++)的问题一致,都是未定义行为,因为存在某条执行路径使得i会在两个相邻的序列点之间被修改两次;如果i是UDT则该写法是良好定义的,跟i = i++一样,但是这种写法也是不推荐的,因为标准对于函数参数的求值顺序是unspecified,因此哪个i++先计算是不能预计的,这仍旧会带来移植性的问题,这种写法应该避免
4. 编译器的跨序列点优化
根据前述讨论可知,在同一个表达式内对于同一个变量i,允许的行为是
A. 不读取,改写一次,例如
|
|
|
对于情况B和C,编译器是有一定的优化权利的,它可以只读取一次变量的值然后直接使用该值多次
但是,当该变量是volatile-qualified类型时编译器允许的行为究竟如何目前还没有找到明确的答案,ctrlz认为如果在两个相邻序列点之间读取同一个volatile-qualified类型对象多次仍旧是undefined behavior,原因在于该读取动作有副作用且该副作用等价于修改该对象,RoachCock的意见是两个相邻的序列点之间读取同一个volatile-qualified类型应该是合法的,但是不能被优化成只读一次。一段在嵌入式开发中很常见的代码示例如下
|
|
|
如果编译器探测到foo()没有任何语句(包括foo()调用过的函数)对flag有过修改,则也许会把(2)优化成只在进入foo()的时候读一次flag的值而不是每次循环都读一次,这种跨序列点的优化很有可能导致死循环。但是这种代码在多线程编程中很常见,虽然foo()没有修改过flag,也许在另一个线程的某个函数调用中会修改flag以终止循环,为了避免这种跨序列点优化带来到错误,应该把flag声明为volatile bool,C++2003对volatile的说明如下
[Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. See 1.9 for detailed semantics. In general, the semantics of volatile are intended to be the same in C++ as they are in C. ]
5. C99定义的序列点列表
— The call to a function, after the arguments have been evaluated.
— The end of the first operand of the following operators:
logical AND && ;
logical OR || ;
conditional ? ;
comma , .
— The end of a full declarator:
declarators;
— The end of a full expression:
an initializer;
the expression in an expression statement;
the controlling expression of a selection statement (if or switch);
the controlling expression of a while or do statement;
each of the expressions of a for statement;
the expression in a return statement.
— Immediately before a library function returns.
— After the actions associated with each formatted input/output function conversion specifier.
— Immediately before and immediately after each call to a comparison function, and also between any call to a comparison function and any movement of the objects passed as arguments to that call.
6. C++2003定义的序列点列表
所有C99定义的序列点同样是C++2003所定义的序列点
此外,C99只是规定库函数返回之后有一个序列点,并没有规定普通函数返回之后有一个序列点,而C++2003则特别指出,进入函数(function-entry)和退出函数(function-exit)各有一个序列点,即拷贝一个函数的返回值之后同样存在一个序列点
需要特别说明的是,由于operator||、operator&&以及operator,可以重载,当它们使用函数语义的时候并不提供built-in operators所规定的那几个序列点,而仅仅只是在函数的所有参数求值后有一个序列点,此外函数语义也不支持||、&&的短路语义,这些变化很有可能会导致难以发觉的错误,因此一般不建议重载这几个运算符
7. C++2003中两处关于lvalue的修改对序列点的影响
在C语言中,assignment operators的结果是non-lvalue,C++2003则将assignment operators的结果改成了lvalue,目前尚不清楚这一改动对于built-in类型有何意义,但是它却导致了很多在合法的C代码在目前的C++中是undefined behavior,例如
|
由于C++2003规定assignment operators的结果是lvalue,因此下列在C99中非法的代码在C++2003中却是可以通过编译的
|
显然按照C++2003的规定这个代码的行为是undefined,它在两个相邻的序列点之间修改了i两次
类似的问题同样发生在built-in类型的前缀++/--operators上,C++2003将前缀++/--的结果从rvalue修改为lvalue,这甚至导致了下列代码也是undefined behavior
|
同样是因为lvalue作为assignment operator的右操作数需要一个左值转换,该转换导致了一个读取动作且这个读取动作发生在修改对象之后
C++的这一改动显然是考虑不周的,导致了很多C语言的习惯写法都成了undefined behavior,因此Andrew Koenig在1999年的时候就向C++标准委员会提交了一个建议要求为assignment operators增加新的序列点,但是到目前为止C++标准委员会都还没有就该问题达成一致意见
posted on 2007-02-07 19:55 局部变量 阅读(1725)