Parameter evaluation order on operator invocations

A

andreas ames

Hi all,

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

if seq.erase(seq.begin(), 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
 
V

Victor Bazarov

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

if seq.erase(seq.begin(), 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.

"Unspecified" 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
 
A

andreas ames

Victor said:
Parentheses seem to be missing around the expression...

You're right, thanks.
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.

See above, I missed the possibility that the past-the-end iterator
might stay valid.
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
 
V

Victor Bazarov

andreas said:
Victor said:
andreas said:
if seq.erase(seq.begin(), 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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,053
Latest member
BrodieSola

Latest Threads

Top