precedence

[Gernot Frisch]

the statement:

foo.b[0] = 7;

indicates the first element of the array member of the data
structure. My
question is, why aren't the brackets evaluated first then the dot
operator
after since the brackets are higher on the precedence chart? Thanks

Er... The content of the braces _is_ evaluated first:

long fkt(void)
{
printf("fkt");
return 0;
}

class FOO
{
public:
long& B(){printf("access B "); return b;}
long b;
};

FOO foo[100];
foo.B()[fkt()] = 7;

 

[Francis Glassborow]

the statement:

foo.b[0] = 7;

indicates the first element of the array member of the data structure. My
question is, why aren't the brackets evaluated first then the dot operator
after since the brackets are higher on the precedence chart? Thanks

Because you start from the name, in this case 'foo' The subscript
operator is not appropriate to foo, and b isn't a free variable but one
that is identified in the context of foo.

 

[Sumit Rajan]

the statement:

foo.b[0] = 7;

indicates the first element of the array member of the data structure. My
question is, why aren't the brackets evaluated first then the dot operator
after since the brackets are higher on the precedence chart? Thanks

A '[]' operator does not have higher precedence than a '.' operator. They
have the SAME precedence.

Regards,
Sumit.

 

[Chris Dollin]

the statement:

foo.b[0] = 7;

indicates the first element of the array member of the data structure. My
question is, why aren't the brackets evaluated first then the dot operator
after since the brackets are higher on the precedence chart? Thanks

(a) because precedence doesn't determine order of evaluation - it determines
what expressions are operands of what operators.

(b) the order of evaluation of the operands of [] is not specfied in
C [dunno about C++, I suspect not].

 

[Andy White]

the statement:

foo.b[0] = 7;

indicates the first element of the array member of the data structure. My
question is, why aren't the brackets evaluated first then the dot operator
after since the brackets are higher on the precedence chart? Thanks

 

[Andrey Tarasevich]

the statement:

foo.b[0] = 7;

indicates the first element of the array member of the data structure. My
question is, why aren't the brackets evaluated first then the dot operator
after since the brackets are higher on the precedence chart? Thanks

Firstly, C++ language does not have a "precedence chart". It has a
grammar, which also happens to determine what we usually refer to as
operator precedence and associativity. And according to C++ grammar, the
above expression should be interpreted as operator '[]' applied to
'foo.b'. Any "precedence charts" are noting more than attempts to more
or less closely represent operator relationship determined by C++
grammar in linear (more readable) form. You just found an example where
the chart you are using doesn't work very well.

Secondly, operator precedence and associativity defines grouping of
operators with their operands? but it doesn't define in any way the
order of evaluation of these operators. Hence, you question about
something being (or not being) "evaluated first" (and/or "evaluated
after") doesn't make much sense in this context.

 

[Francis Glassborow]

Secondly, operator precedence and associativity defines grouping of
operators with their operands? but it doesn't define in any way the
order of evaluation of these operators. Hence, you question about
something being (or not being) "evaluated first" (and/or "evaluated
after") doesn't make much sense in this context.

OK, we have a problem linguistic problem here. Expressions are evaluated
and neither C nor C++ specify the order of evaluation of
sub-expressions. However both provide rules about how operators are
sequenced. The grammar largely specifies the order in which operators
are to be handled. For example

x = a*b*c/d;

allows any order for obtaining values from a, b, c and d but requires
that a*b be evaluated prior to the evaluation of that result * c which
must happen prior to the evaluation of that expression/d.

Where it get complicated is when we have for example:

y = (a+b) * (c+d);
Now either a+b or c+d can be evaluated first because there is no
ordering applied to multiple instances of expressions in parentheses.

Clear as mud to most people. Basically do not write code where the order
in which the sub-expressions are evaluated makes any difference to the
result.

 

[Andrey Tarasevich]

OK, we have a problem linguistic problem here. Expressions are evaluated
and neither C nor C++ specify the order of evaluation of
sub-expressions. However both provide rules about how operators are
sequenced. The grammar largely specifies the order in which operators
are to be handled. For example

x = a*b*c/d;

allows any order for obtaining values from a, b, c and d but requires
that a*b be evaluated prior to the evaluation of that result * c which
must happen prior to the evaluation of that expression/d.

No, it does not require that.

It is worth noting that it is difficult to come to a definite answer in
this case, because we are taking about built-in operators and there's no
way to detect the order in which built-in operators are invoked by the
implementation. For this very reason I don't like the notion of "order
of evaluation" applied to built-in operators.

Grouping between operand and operators ultimately defines the _result_
of the expression, but not the order of evaluation of its
subexpressions. The implementation is free to choose absolutely any
method of evaluation that leads to the correct result. In the above case
the compiler is free to start with evaluating, say, 'b/d' if it knows
how to ensure that the final value in 'x' is correct.

It is worth noting that in many cases order of evaluation is tied to the
correctness of the result much more than it would be in abstract
mathematics (like in situations when intermediate subexpressions can
produce overflows, precision loss etc). In such cases evaluating the
expression in "canonical" order (defined by precedence and
associativity) is the most straightforward way to ensure that the result
is correct. But, once again, the compiler is not required to do it this way.

Where it get complicated is when we have for example:

y = (a+b) * (c+d);
Now either a+b or c+d can be evaluated first because there is no
ordering applied to multiple instances of expressions in parentheses.

This expression can also be evaluated as the sum of 'a*c', 'a*d', 'b*c'
and 'b*d', if the compiler chooses to so for some reason and is capable
of ensuring that the final result is correct.

Clear as mud to most people. Basically do not write code where the order
in which the sub-expressions are evaluated makes any difference to the
result.

Yes, as long as there are no side effects. Side effect make things much
more complicated. I've seen people, who'd erroneously apply the above
rule and come to the conclusion that the following expression is OK,
because it "doesn't depend on the order of evaluation":

const int a[] = { 1, 2, 3 };
const int* p = a;

int sum = *p++ + *p++ + *p++; // <- this one

 

[Victor Bazarov]

[...]
It is worth noting that in many cases order of evaluation is tied to the
correctness of the result much more than it would be in abstract
mathematics (like in situations when intermediate subexpressions can
produce overflows, precision loss etc). In such cases evaluating the
expression in "canonical" order (defined by precedence and
associativity) is the most straightforward way to ensure that the result
is correct. But, once again, the compiler is not required to do it this way.

Pardon the interruption...

I know that "notes" are not normative, but 1.9/15, while being a note,
does talk about the compiler being prohibited from rewriting expressions
in such way that it might produce an exception in certain cases.

Is this what you mean by "not required"? And if it's not really required,
why does the Standard contain the words "the implementation cannot rewrite
this expression"?

[...]

Victor

 

[Andrey Tarasevich]

[...]
It is worth noting that in many cases order of evaluation is tied to the
correctness of the result much more than it would be in abstract
mathematics (like in situations when intermediate subexpressions can
produce overflows, precision loss etc). In such cases evaluating the
expression in "canonical" order (defined by precedence and
associativity) is the most straightforward way to ensure that the result
is correct. But, once again, the compiler is not required to do it this way.

Pardon the interruption...

I know that "notes" are not normative, but 1.9/15, while being a note,
does talk about the compiler being prohibited from rewriting expressions
in such way that it might produce an exception in certain cases.

Is this what you mean by "not required"? And if it's not really required,
why does the Standard contain the words "the implementation cannot rewrite
this expression"?

[...]

When used the term "result" in my previous message, I used it in its
broader meaning than the one assumed in C++ standard. My mistake. What I
really meant might be best referred to as, say, "outcome" of the
evaluation process, which includes obtaining result as well as, for
example, generating (or not generating) the exception mentioned in the note.

I don't argue that one elegant way to describe the evaluation of
expressions in C++ is to use the "as if" rule, i.e. to say that
expressions are evaluated "as if" the exact order of evaluation is
defined by operator precedence and associativity. The only problem I see
with it is that often in practical situations the meaning of "as if" in
the above sentence gets misunderstood or lost completely.