Parameter evaluation order on operator invocations

[andreas ames]

Hi all,

recently I came across a line of code like the following:

if seq.erase(seq.b egin(), seq.end()) != seq.end()
/* ... */

It made me wonder if this is just bogus or if it even can invoke
undefined behaviour.

The answer depends, AFAICT, on the sequence of evaluation of both of
the parameters of operator!=.

1) I've read that the evaluation order of normal function parameters is
not defined.

2) OTOH, I seem to remember that at least some operators (&&, ||)
define a short-circuit logic (is this the right english term?), i.e.
the second parameter to operator&& is only ever evaluated if the first
one evaluates to true.

So the real question is: Are parameters of all operator calls
evaluated in their natural order (the same order in which the arguments
were declared), such that the code above just was bogus or is the order
only defined for certain special operators?


TIA,

aa

[Victor Bazarov]

Re: Parameter evaluation order on operator invocations

andreas ames wrote:

recently I came across a line of code like the following:
>
if seq.erase(seq.b egin(), seq.end()) != seq.end()
/* ... */

Parentheses seem to be missing around the expression...

It made me wonder if this is just bogus or if it even can invoke
undefined behaviour.

It can be. It can invoke UB. All depens on what 'seq' is.

The answer depends, AFAICT, on the sequence of evaluation of both of
the parameters of operator!=.

Why?

1) I've read that the evaluation order of normal function parameters
is not defined.

"Unspecifie d" is the preferred term.

2) OTOH, I seem to remember that at least some operators (&&, ||)
define a short-circuit logic (is this the right english term?), i.e.
the second parameter to operator&& is only ever evaluated if the first
one evaluates to true.

That's so only for built-in logical operators. BTW, that's why it is
not a good idea to overload those.

So the real question is: Are parameters of all operator calls
evaluated in their natural order (the same order in which the
arguments were declared), such that the code above just was bogus or
is the order only defined for certain special operators?

Overloaded operators are NO exception to the "evaluation order of
function argument is unspecified" rule. However, the code above is
not necessarily bogus *iff* erasure in 'seq' does _not_ invalidate
the 'end' iterator (since it's not the one being erased).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[andreas ames]

Re: Parameter evaluation order on operator invocations

Victor Bazarov wrote:

andreas ames wrote:

if seq.erase(seq.b egin(), seq.end()) != seq.end()
/* ... */

>
Parentheses seem to be missing around the expression...

You're right, thanks.

It made me wonder if this is just bogus or if it even can invoke
undefined behaviour.

>
It can be. It can invoke UB. All depens on what 'seq' is.

Oh, I missed that possibility (that there are sequences that don't
invalidate the past-the-end iterator, when contents are deleted).
Thanks for the hint.

The answer depends, AFAICT, on the sequence of evaluation of both of
the parameters of operator!=.

>
Why?

See above, I missed the possibility that the past-the-end iterator
might stay valid.

2) OTOH, I seem to remember that at least some operators (&&, ||)
define a short-circuit logic (is this the right english term?), i.e.
the second parameter to operator&& is only ever evaluated if the first
one evaluates to true.

>
That's so only for built-in logical operators. BTW, that's why it is
not a good idea to overload those.

Aha, I didn't know, that this doesn't hold for overloaded logic
operators.

Overloaded operators are NO exception to the "evaluation order of
function argument is unspecified" rule. However, the code above is
not necessarily bogus *iff* erasure in 'seq' does _not_ invalidate
the 'end' iterator (since it's not the one being erased).

I think it's still bogus (even for sequences with more durable
past-the-end operators) because I fail to see how the 'then' branch of
the if statement could ever be reached. Am I still missing sth.?


cheers,

aa

[Victor Bazarov]

Re: Parameter evaluation order on operator invocations

andreas ames wrote:

Victor Bazarov wrote:

>andreas ames wrote:

>>if seq.erase(seq.b egin(), seq.end()) != seq.end()
>>/* ... */

>[..]

>
I think it's still bogus (even for sequences with more durable
past-the-end operators) because I fail to see how the 'then' branch of
the if statement could ever be reached. Am I still missing sth.?

The bogusness of any code is in the eye of the beholder. The 'then'
branch may contain some code that when compiled achieves certain code
behaviour (instantiation of a template, for example), but does not
need to be executed. Without seeing the entire program how can we
label anything in it "bogus"? Take this example:

/* code fragment */
i =
/* end of fragment */

isn't it obvious how totally bogus it is?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask