Re: expressions and order of evaluation
On Nov 23, 8:39 pm, Taras_96 <taras...@gmail.com> wrote:
I have a couple of questions about expressions and the
subsequent order of evaluation.
Firstly, as I understand it, an expression is what wiki
defines it to be: "An expression in a programming language is
a combination of values, variables, operators, and functions
that are interpreted (evaluated) according to the particular
rules of precedence and of association for a particular
programming language, which computes and then produces
(returns, in a stateful environment) another value".
In C++, an expression doesn't necessarily return a value, or
even return. (In C++, "(void)0" and "throw something" are
expressions.)
I am also aware that expressions can be grouped into
sub-expressions.
eg: 2 + 3 + 4 can be thought of as two expressions, (2+3) & 5 + 4
According to TCPL (Bjarne Stroustrup), the order of evaluation
of sub-expressions is not defined. Because of this, I'm
guessing that how a compound expression is decomposed into a
sub-expression can effect whether an expression is defined or
not. How is a compound expression decomposed into atomic
sub-expressions? Is it according to precedence & associativity
rules?
eg: the addition operator is right-associative. If we have the
expression:
f() + g() + h()
Which, because the addition operator is left associative, can
be written (into 'atomic' sub-expressions) as
( f() + g() ) + h()
Then is it the case that we can't guarantee whether h() gets
evaluated first or second, but *can* we guarantee that IF f()
IS evaluated before h(), then the expression ( f() + g() )
will be evaluated before h() (ie: sub-expressions get
evaluated as a complete unit)?
No. A compiler is allowed to evaluate all of the functions
first, then do the two additions. The only things constraining
ordering are direct dependencies (f() and g() must both be
evaluated before their results are added) and something called
sequence points. Sequence points only introduce a partial
ordering, however, and very few operators induce a sequence
point.
--------------------------------------------
Bjarne also writes that the expression
int i = 1;
v[i] = v[i++];
is undefined: "may be evaluated as either v [1 ]=1 or v [2 ]=1
or may cause some even stranger behavior."
This comes as a surprise, as I would have thought that the RHS
of an assignment operator would be evaluated before the LHS!
There are two issues here. The first is that the compiler can
evaluate either side of the assignment first, or even do parts
of one side, then parts of the other. (Note too that while Java
does impose an order, it requires the left hand side of an
assignment to be evaluated first. I'm not sure from where you
get the idea that that right hand side should be evaluated
first.)
The second is that the language imposes some constraints
regarding what a legal program can do in an expression. In
particular "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." Otherwise, you get undefined behavior. Since your
expression contains no sequence points, it's undefined behavior.
(I've probably forgotten some exotic cases, but the end of the
full expression, the &&, || ?: and comma operators, and a
function call or a return are sequence points. Note that they
don't necessarily impose a full ordering; a compiler can still
intermingle the evaluation of a functions arguments with other
parts of the expression; all of the side effects of evaluating
the function's arguments must occur before the function is
called, however.)
By the same virtue, does it mean that v[i] = v[++i] is also
undefined? (if my understanding of post/pre fix operators is
correct).
Yes. For the same reasons.
Does this mean that the following is also undefined?
class A
{
int a;
public:
int & returnA( return a;}
}
returnA() = 3 + 2;
as we don't know whether returnA() is evaluated first or 3+2
is evaluated first? I would think the 'logical' choice would
be that 3+2 would be evaluated first...
In this case, it almost certainly will be---I don't know of a
compile that won't evaluate 3+2 at compile time:-). More
generally, however, there's no real reason; one popular strategy
is to evaluate which ever side requires the most registers
first.
------------------
A c++ expression always evaluates to a value,
No, you can have void expressions in C++.
so x = 3 + 2 is
an expression that actually evaluates to 5...
An important side note here: an expression has a type; if the
type isn't void, it also has a value. The type can affect the
results: if x is an unsigned char, and UCHAR_MAX is 255, then
the results of
x = 1024
are 0, since the expression has type unsigned char, and the
results must be a value which can be represented in an unsigned
char.
so in y=x=3+2, y get's assigned the value of (x = 3 + 2),
which is 5. Is it always the case that the evaluated value for
a statement involving an assignment operator is always what
both individual sides evaluate to (I assume that this is the
case)?
Sort of, depending on what you consider the "right hand side".
After evaluating the right hand side, the resulting value (which
has a type) is converted to the type of the left hand side, and
it is the converted value which is assigned, and is the value of
the expression.
I also guess that this does not hold true for user defined
types, as theoretically you could return anything from the
operator= function
Correct. More generally, precedence and associativity determine
how the expression is parsed. Then overload resolution is
applied to each operator. If overload resolution resolves to a
user defined operator, all further considerations deal with the
function. This includes the return type, lvalue-ness (and
lvalue requirements) and sequence points.
------------------
Finally, at http://tiny.cc/6C2UA, Victor Bazarov states that
expression x[x[0]] = 2 is not conforming "for one simple reason:
you're accessing and changing the value of x[0] in the same
expression."
That's a tricky one (supposing x[0] contains 0). Technically,
according to the current wording, I think he's right; if x[0]
contains 0, you're modifying x[0], and you're accessing it other
than to determine the value to be stored (which is independent
of the value of x[0]). In this case, I'm not sure that this was
intended (you obviously can't modify x[0] until you've read it).
Everything concerning ordering constraints, etc., has recently
been rewritten to take multithreaded environments into
consideration; the next version of the standard uses the concept
of sequencing (an operation is sequenced before, unsequenced or
indeterminately sequenced), rather than sequence points. I've
not read it in enough detail to be sure, but I think it will
result in the above being defined. There is a sentence: "The
value computations of the operands of an operator are sequenced
before the value computation of the result of the operator." And
the "undefined behavior" being considered here is defined by the
following sentence "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." If I understand
this correctly, in the above expression, the evaluation of x[0]
is part of the value computations of the operands of the
assignment operator (along with x[x[0]]), and so is sequenced
before the actual assignment. Which means that the expression
does not contain undefined behavior.
x[0] = 0;
x[2] = 123;
x[x[0]] = 2;
Could someone explain this a bit further?
There's no real logical explination. It's just what the
standard says.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34