[Cython] Out of order side effects of argument evaluation in function calls (ticket #654)

[Stefan Behnel]

Stefan Behnel, 11.03.2011 15:08:
> Vitja Makarov, 11.03.2011 15:04:
>> 2011/3/11 Stefan Behnel:
>>> Personally, I think it would be nice to keep up Python's semantics, but
>>> when
>>> I implemented this I broke quite some code in Sage (you may have noticed
>>> that the sage-build project in Hudson has been red for a while). There are
>>> things in C and especially in C++ that cannot be easily copied into a
>>> temporary variable in order to make sure they are evaluated before the
>>> following arguments. This is not a problem for Python function calls where
>>> all arguments end up being copied (and often converted) anyway. It is a
>>> problem for C function calls, though.
>>
>>> f(g(a), a.x, h(a))
>>
>> Why could not this be translated into:
>>
>> tmp1 = g(a)
>> tmp2 = a.x
>> tmp3 = h(a)
>>
>> f(tmp1, tmp2, tmp3)
>
> See above.

To be a little clearer here, it's a problem in C for example with struct 
values. Copying them by value into a temp variable can be expensive, 
potentially twice as expensive as simply passing them into the function 
normally.

Not sure what kind of additional devilry C++ provides here, but I'd expect 
that object values can exhibit bizarre behaviour when being assigned. Maybe 
others can enlighten me here.

I have no idea how many cases there actually are that we can't handle or 
that may lead to a performance degradation when using temps, but the 
problem is that they exist at all.

Stefan