> On Nov 25, 2015, at 1:25 PM, Martin Sebor <mse...@gmail.com> wrote: > > On 11/24/2015 02:55 AM, Andrew Haley wrote: >> On 23/11/15 23:01, Jason Merrill wrote: >>> There's a proposal working through the C++ committee to define the order >>> of evaluation of subexpressions that previously had unspecified ordering: >>> >>> http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf >>> >>> I agree with much of this, but was concerned about the proposal to >>> define order of evaluation of function arguments as left-to-right, since >>> GCC does right-to-left on PUSH_ARGS_REVERSED targets, including x86_64. >>> >>> Any thoughts? >> >> Not about PUSH_ARGS_REVERSED targets, but my two-penn'orth: >> >> The proposal seems to be a bit of a minefield. This one: >> >> a(b, c, d) >> >> is a bit counter-intuitive. I wouldn't expect a to be evaluated before >> the arg list. I wonder how many C++ programmers would. > > The motivating example in the paper suggests that many C++ > programmers expect a left to right order of evaluation here > due to the commonality of constructs like chains of calls. > > Incidentally, both GCC and Clang evaluate the first operand > of the function call expression first in C as well in C++ > (the program below prints a b c d when compiled with GCC, > and a d c b with Clang). > > Interestingly, though, not all compilers take that approach. > IBM XLC, for example, evaluates it last (and the program below > prints b c d a).
I thought the order depends on target architecture, because of the argument passing rules. I distinctly remember seeing right to left on x86 (because they are pushed on the stack, leftmost argument on top) and left to right on MIPS (because they go into registers, at least the first 4 or 8 arguments). I'm really wondering about this proposal. It seems that it could affect optimization. It also seems to be a precedent that may not be a good one to set. Consider the dozen or so "undefined behavior" examples in https://pdos.csail.mit.edu/papers/ub:apsys12.pdf -- would the committee want to remove ALL of those? If yes, what will that do to performance? If no, what are the criteria by which to decide yes or no for each individual example? And I assume there are probably more "things the beginning programmer wouldn't expect" issues in C and C++. paul
