Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Parameter evaluation order on operator invocations

Reply
Thread Tools

Parameter evaluation order on operator invocations

 
 
andreas ames
Guest
Posts: n/a
 
      10-23-2006
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

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      10-23-2006
andreas ames wrote:
> 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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


 
Reply With Quote
 
 
 
 
andreas ames
Guest
Posts: n/a
 
      10-23-2006
Victor Bazarov wrote:
> andreas ames wrote:
> > if seq.erase(seq.begin(), 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

 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      10-23-2006
andreas ames wrote:
> Victor Bazarov wrote:
>> andreas ames wrote:
>>> 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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Operator evaluation order boltar2003@boltar.world C++ 16 05-15-2011 01:24 PM
Evaluation order and operator precedance Frédéric C++ 4 12-06-2007 04:09 PM
Evaluation order of comma operator mr.gsingh@gmail.com C++ 1 12-15-2006 11:50 AM
Invocations (was: How to implement tab order?) Stefan Ram Java 20 05-02-2006 08:32 PM
Order of evaluation -- clash w/sequentiel expression operator Jan Engelhardt C Programming 3 08-20-2003 09:07 PM



Advertisments