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

On Sun, 5 Oct 2003 00:21:15 -0700, "cheeser" <cheeser_1998@yahoo.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.

"cheeser" <cheeser_1998@yahoo.com> wrote in message
news:%DPfb.7978$La.3766@fed1read02...[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

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.