1

I know that the evaluation order of arguments to a function is unspecified (e.g. see here). According to this SO question, there seems to be a workaround to overcome this, which however doesn't seem to work reliably on all systems (I'm targeting iOS and Mac OS).

So, my question is: Does this undefinedness of evaluation order also apply to variadic functions, in C and Objective-C? Or is the evaluation order then actually defined?

Community
  • 1
  • 1
benjist
  • 2,740
  • 3
  • 31
  • 58
  • 2
    In C, in `printf("%d %d %d", foo(), bar(), zip())` the order of evaluation of the three function calls is unspecified. – Kerrek SB Jul 08 '13 at 00:01
  • 2
    No, it isn't defined, why would the case be better for variadic functions? –  Jul 08 '13 at 00:03
  • @H2CO3 because I was hoping for that the arg list would be handled beginning with the first argument. I thought also it is not the case, but I hoped for it (because now I need to get my hands dirty). – benjist Jul 08 '13 at 00:12
  • @benjist Since all the arguments have to be evaluated before the function could be even called, all the evaluations must happen in one batch before the call. Now the order in which the results are pushed onto the call stack is a different question. –  Jul 08 '13 at 00:13
  • @Kerrek SB: Thanks. Too bad that this is the case. Do you want to make this an answer? – benjist Jul 08 '13 at 00:14
  • 1
    @benjist: It's not really that bad. If you were to write code that *depends* on the order of function argument evaluation, you'd just make everyone else's lives miserable who has to read and understand your code. – Kerrek SB Jul 08 '13 at 00:15
  • @Kerrek SB: I actually have that one rare situation where it will make a users (==developers) life much more comfortable. I'm implementing a query builder where each function call returns the same instance of the builder, which enables nice and short SQL building code. A "nestedAnd" to my where clause now could have taken various types, including instances of itself which could create more logic conditions. So it is not possible in an easy way to do it, because obviously the order of evaluation matters here indeed. – benjist Jul 08 '13 at 00:27
  • ...(continued) because each of the calls to the query builder instance changes the "where" condition tree. Since I cannot preserve the order of execution, all nodes that are provided or created before the actual function call (unary operators, binary ops, consts,...) are appended in wrong order. – benjist Jul 08 '13 at 00:47

0 Answers0