Why doesn't c++ have a specified order for eva

Question

It seems to me that it's a very basic and necessary feature of any functional programming language to know the order in which the arguments of a function call will be evaluated. Am I wrong in this? Why doesn't C++ define this? Is it being discussed for any future version of C++?

Answer 1

Why doesn't C++ do it this way?

For starters, C++ isn't a functional programming language.

And the fastest way to evaluate the arguments depends on the implementation and architecture, so the compiler gets to choose. We don't pay for what we don't use, in C++, so if you need to specify an evaluation order yourself then you can do so explicitly with named variables.

Although, continuing the theme of newer standards leaving behind sacred C++ paradigms, C++17 will sadly add some evaluation order guarantees, ruining all of that.

Answer 2

As of C++17 it guarantees arguments will be evaluated linearly and will not interleave but not in any specific order - https://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-52-ISO-C-Oulu-Debriefing

The reason it didn't before was to allow compiler implementers the scope to optimise the order of evaluation, it turned out not to be used or to be used poorly to the extent that logical order can and will be enforced with negligible impact.

EDIT: correction, thanks @Oktalist

I actually think this is an odd decision, it seems obvious to me that interleaving is an easier optimisation than argument evaluation reordering and I don't think we're going to treat argument evaluation with any more trust than we did before.

Answer 3

C++ is not a functional programming language. In fact in such a language (with no side effects), order of evaluation would not matter.

C++ leaves as much as practical up to the implementation of the compiler, especially where optimization opportunities might occur. Before fixing something like this, existing compiler writers are consulted to see if there is a cost.

Some order of evaluation guarantees surrounding overloaded operators and complete-argument rules were added in C++17. But it remains that which argument goes first is left unspecified. In C++17, it is now specified that the expression giving what to call (the code on the left of the ( of the function call) goes before the arguments, and whichever argument is evaluated first is evaluated fully before the next one is started, and in the case of an object method the value of the object is evaluated before the arguments to the method are. (There may be some minor errors in this description: ask a narrow question about it for a more vetted answer).

These were vetted and determined to not cause significant problems for existing compilers. Reordering of arguments was considered, and discarded, presumably for good reasons. Or even poor reasons, like existing compilers have a default order and it could break (possibly non-compliant) code on that compiler to force them all to do it in one global order.

In short, C++ leaves lots of freedom to compiler writers. This has let compiler writers find optimization opportunities in strange crannies. The kind of optimizations available today are way beyond what the original writers of C, let alone C++, may have suspected were practical or be considered reasonable.