Ok... in C++ is it true that parameters are passed from right to left?

I mean if the comma operator is invoked <lowest precedence operator>
then it makes sense that this is defined with the following behavior:

void f (int a, int b, int c) {
   cout << a << ' ' << b << ' ' << c << endl;
}

int main () {
 int d=1;
 f(d++, d++, d++);
 }

Output is:
 3 2 1

The right side of the comma operator being evaluated first.
So the rightmost d++ is evaluated first passing the value of d then
incrementing it.

I guess my question is really does the comma operator apply to parameter
lists and if not why not?  Sounds like a good way to define what may be
undefined behavior :)

Am I correct?  Objections?

Dave Leimbach

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Sun,  3 Jun 2001 20:10:24 GMT, dave <dleimbac@earthlink.net> wrote:
> Ok... in C++ is it true that parameters are passed from right to left?

No, it is not true.

> I guess my question is really does the comma operator apply to
> parameter lists and if not why not?

No, it doesn't, the formal reason being that the syntax just isn't
defined that way. Also, the result of the comma operator is not a pair
of values, but only the value of the right-hand expression, hence only
one value would get passed to the function. [E.g. in

   f( (++d, ++d, ++d) )

where the commas _are_ comma operators, only one argument is passed to
f(), namely the value of d after the third increment.]

The order of evaluation of the expressions in the argument list of a
function invocation is completely unspecified.

This is pretty much the same as when you have

   (expr_a + expr_b + expr_c)

where the order of evaluation of expr_a-c is unspecified.

> Sounds like a good way to define what may be undefined behavior :)

Your example

   f(++d, ++d, ++d)

invokes undefined behavior, but not merely because the order of
evaluation is undefined. The standard mandates the following:

   Between the previous and next sequence point a scalar object shall
   have its stored value modified at most once by the evaluation of an
   expression. Furthermore, the prior value shall be accessed only to
   determine the value to be stored.

Since there is no sequence point between the `++d' expressions
(precisely because the commas don't act as comma operators), your
code is therefore not conforming. A conforming example would be:

   void foo(const char *s) { std::cout << s << endl; }

   f((foo("a"), d),
     (foo("b"), d + 1),
     (foo("c"), d + 2))

where the order of the invokations of foo() would still be unspecified,
but behaviour would not be undefined.

Making all this strictly defined would make a lot of optimizations
impossible. In other words, you better forget about this. :)

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

dave wrote:
>
> Ok... in C++ is it true that parameters are passed from right to left?

No.

> I mean if the comma operator is invoked <lowest precedence operator>

The comma you see in an argument list or a parameter list is NOT a comma
operator. In the statement:

 f((a,b),c,d);

The first comma is a comma operator; the remaining commas are merely
puctuation that is part of the function-call operator. This is, in
principle, no different from the fact that "<<" indicate a shift
operator, not two separate less-than operators.

> then it makes sense that this is defined with the following behavior:
>
> void f (int a, int b, int c) {
>    cout << a << ' ' << b << ' ' << c << endl;
> }
>
> int main () {
>  int d=1;
>  f(d++, d++, d++);
>  }

The order in which the arguments to a function are evaluated is
unspecified, so you could get 1,2,3, or 3,2,1, or 2,1,3.  It gets worse.
Since there are no sequence points separating the three d++ expressions
there's no guarantee that the value of d will get updated by any of them
until after all three have been evaluated - you could end up with 1,1,1,
or 1,1,2, or 1,2,2. However it gets even worse. All three expressions
involves changing the value of the same object, with no intervening
sequence point. That allows undefined behavior - in principle, anything
could happen; it could format your hard drive, send threatening e-mail
to your boss, or start composing lullabies.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <87snhilq83.fsf@mutt.home.net>, dave <dleimbac@earthlink.net>
writes
>I guess my question is really does the comma operator apply to parameter
>lists and if not why not?  Sounds like a good way to define what may be
>undefined behavior :)

No, commas in parameter lists are merely punctuators and are not
operators so the whole of your deductions are false (dangerously so)


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]