Parameter evaluation order on operator invocations

Discussion in 'C++' started by andreas ames, Oct 23, 2006.

  1. andreas ames

    andreas ames Guest

    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
     
    andreas ames, Oct 23, 2006
    #1
    1. Advertising

  2. 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
     
    Victor Bazarov, Oct 23, 2006
    #2
    1. Advertising

  3. andreas ames

    andreas ames Guest

    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
     
    andreas ames, Oct 23, 2006
    #3
  4. 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
     
    Victor Bazarov, Oct 23, 2006
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stefan Ram
    Replies:
    20
    Views:
    859
    Roedy Green
    May 2, 2006
  2. Jan Engelhardt
    Replies:
    3
    Views:
    381
    Mike Wahler
    Aug 20, 2003
  3. Replies:
    1
    Views:
    402
    Gavin Deane
    Dec 15, 2006
  4. Frédéric
    Replies:
    4
    Views:
    337
    James Kanze
    Dec 6, 2007
  5. Replies:
    16
    Views:
    573
    James Kanze
    May 15, 2011
Loading...

Share This Page