Talk:Comma operator

Use?

Is there any common-ish use case for the comma operator? It seems like it would allow typo'd code to compile more often than actually doing anything useful. Psychlohexane (talk) 18:51, 11 April 2012 (UTC)[reply]

It can be used as a Sequence point. For example, you could increment a second unrelated variable at every iteration of a loop by doing something like for (i = 0; i < 10; j++, i++) (head code), where a normal C statement would not be permitted. I'm not sure whether this is either particularly common or regarded as good practice. 82.113.148.68 (talk) 13:20, 28 May 2012 (UTC)[reply]

It can be used to concisely show a relationship between two things like: if (badThing) return (errno = EINVAL, -1); -- here the side-effect of assigning to the global errno and the return code (-1) indicating an error occurred (and the caller should check errno). 75.162.33.157 (talk) 18:18, 11 August 2012 (UTC)[reply]

Thanks for the good question and responses! The main use case, as noted, is in the initializer and increment of for loops, though there are a few other uses. I’ve written them up in Comma operator#Uses, in edits ending in this edit. Hope these help, and please edit!

—Nils von Barth (nbarth) (talk) 13:15, 9 December 2012 (UTC)[reply]

I came across another usage yesterday. You can use the operator to check, if a specific function can be called with the current compiler or not, if yes call it, otherwise call a fallback. Usefull for crossplatform development. http://stackoverflow.com/questions/1386183/how-to-call-a-templated-function-if-it-exists-and-something-else-otherwise — Preceding unsigned comment added by Uwe Gebhardt (talk • contribs) 12:22, 4 January 2013 (UTC)[reply]

This article needs to mention that Stroustrup's comment about the usefulness of operator-comma was probably meant to indicate that it's not very useful to redefine or overload this operator, as opposed to merely using it. The problem is that redefining the operator results in destroying the operator precedence and the evaluation order!

For example, if I were to write something like: a = b.foo(), c.bar(); then it is normally guaranteed that foo() will be called first, its result thrown away, then bar() called second, and its result assigned to "a".

NOT So if you've overloaded the comma operator! Now it is simply a function call, and the C++ compiler is entirely within its rights (according to the language definition) to evaluate its arguments in either order it prefers.

— Forbin1 (talk) 18:46, 18 February 2014 (UTC)[reply]

FWIW, beside their use in for-loops, I have found the comma operator useful for both horizontal and vertical brevity in switch statements, for example in a simple character-by-character state machine:

       while (state) switch ((c = *src++), state) {
               case 1:
                       if (c == 'x') ...
                       ...
               case 9:
                       if (c == 'y') ...
                       ...
                       state = 0; /* exit sm */
       }

Instead of:

       while (state) {
               c = *src++;
               switch (state) {
                       case 1:
                               if (c == 'x') ...
                               ...
                       case 9:
                               if (c == 'y') ...
                               ...
                               state = 0; /* exit sm */
           }
       }

without any significant loss of clarity. 173.23.44.8 (talk) 19:17, 22 May 2018 (UTC)[reply]

Problem in examples

In the examples there is a problem in the fifth line: The result of "i = a += 2" is not defined by the C standard. The C compiler can decide to compile the statements composing the whole in the following way:

 t1 = a+2
 a = t1
 i = a

where "t1" is some temporary storage, but could also shuffle the second and third lines like this

 t1 = a+2
 i = a
 a = t1

since there is only a sequence point after the "2". The original author of the examples seems to have intended the second way, gcc on my computer chooses the first. As this is undefined by the C standard I would remove that example. 134.169.77.186 (talk) 10:26, 26 July 2012 (UTC) (ezander)[reply]

This is completely wrong and has nothing to do with sequence points, your argument could be applied to + as well, claiming "i = a + 2" is undefined because the compiler could chose to evaluate it as "i = a; 2", but this is obviously not the case. Assignment operators (including +=) are expressions with a well defined meaning and result, regardless of evaluation order. The C standard thus defines "i = a += 2" as "a += 2; i = a" (apart from the extra evaluation). There is nothing ambiguous or undefined about it. 194.126.175.154 (talk) 23:42, 18 February 2015 (UTC)[reply]