Evaluation order for nested function calls

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • cheeser

    Evaluation order for nested function calls

    Hello all,

    Consider nested function calls:

    foo1(
    foo2( foo3()),

    foo4(
    foo5(),
    foo6(foo7())
    ),

    foo8()
    );

    There are obvious dependencies here such as that foo3() must be called
    before foo2(). Other than the required dependencies of this ilk, is there
    any guarantee that these 8 function calls will be made in any particular
    order?

    The two (slightly different) orderings shown below meet the obvious
    dependencies just described. What I would like to know though is if they
    are *both* within the realm of Standard-conforming behavior.

    ORDER 1:
    foo7()
    foo8()
    foo3()
    foo5()
    foo2()
    foo6()
    foo4()
    foo1()

    ORDER 2:
    foo7()
    foo3()
    foo5()
    foo2()
    foo6()
    foo4()
    foo8()
    foo1()

    The obvious concern here is that the lack of a completly well-defined order
    could cause the same program to behave differently under two different
    compilers.

    Thanks,
    Dave


  • Alf P. Steinbach

    #2
    Re: Evaluation order for nested function calls

    On Sun, 5 Oct 2003 00:21:15 -0700, "cheeser" <cheeser_1998@y ahoo.com> wrote:
    [color=blue]
    >Consider nested function calls:
    >
    >foo1(
    > foo2( foo3()),
    >
    > foo4(
    > foo5(),
    > foo6(foo7())
    > ),
    >
    > foo8()
    > );
    >
    >There are obvious dependencies here such as that foo3() must be called
    >before foo2(). Other than the required dependencies of this ilk, is there
    >any guarantee that these 8 function calls will be made in any particular
    >order?[/color]

    No.


    [color=blue]
    >...
    >The obvious concern here is that the lack of a completly well-defined order
    >could cause the same program to behave differently under two different
    >compilers.[/color]

    That's generally the case when you use side-effects.

    Avoid side-effects.

    Comment

    • Mike Wahler

      #3
      Re: Evaluation order for nested function calls


      "cheeser" <cheeser_1998@y ahoo.com> wrote in message
      news:%DPfb.7978 $La.3766@fed1re ad02...[color=blue]
      > Hello all,
      >
      > Consider nested function calls:
      >
      > foo1(
      > foo2( foo3()),
      >
      > foo4(
      > foo5(),
      > foo6(foo7())
      > ),
      >
      > foo8()
      > );
      >
      > There are obvious dependencies here such as that foo3() must be called
      > before foo2(). Other than the required dependencies of this ilk, is there
      > any guarantee that these 8 function calls will be made in any particular
      > order?[/color]

      No.
      [color=blue]
      >
      > The two (slightly different) orderings shown below meet the obvious
      > dependencies just described. What I would like to know though is if they
      > are *both* within the realm of Standard-conforming behavior.
      >
      > ORDER 1:
      > foo7()
      > foo8()
      > foo3()
      > foo5()
      > foo2()
      > foo6()
      > foo4()
      > foo1()
      >
      > ORDER 2:
      > foo7()
      > foo3()
      > foo5()
      > foo2()
      > foo6()
      > foo4()
      > foo8()
      > foo1()
      >
      > The obvious concern here is that the lack of a completly well-defined[/color]
      order[color=blue]
      > could cause the same program to behave differently under two different
      > compilers.[/color]

      Yes it can.

      #include <iostream>

      int foo(int i, int j)
      {
      return i - j;
      }

      int main()
      {
      int x = 0;
      int y = 0;

      std::cout << foo(x = 42, y = x);
      return 0;
      }

      Output could be 42 or 0.

      -Mike


      Comment

      • Julián Albo

        #4
        Re: Evaluation order for nested function calls

        cheeser escribió:
        [color=blue]
        > The obvious concern here is that the lack of a completly well-defined order
        > could cause the same program to behave differently under two different
        > compilers.[/color]

        The solution is simple: don't write a program like that. If you need a
        precise order call the functions as desired, with sequence points
        between, storing the results in temporaries and the order of execution
        will be guaranteed.

        If the order of the calls has no effect in the behaviour you can leave
        as tou write, and there is a chance that the optimizer generate a better
        code.

        Regards.

        Comment

        Working...