overloading of ","

[josh]

Hi, I coded the following but It does not return what I expect, why?

#include <iostream>

using namespace std;

class Other
{
public:
int i;

Other(int x=1)
{
i = x;
}

Other *operator-() { return this;}

Other &operator+ (Other t)
{
i += t.i;

return *this;
}

Other &operator,(Othe r oth)
{
i = oth.i;

return *this;
}

};

int main()
{
Other o0, o1, o2(4), o3(5);

o0->i = 100;

cout << o0.i << "\n" << o0->i << "\n";

// HERE it returns 5 AND not 6 WHY ??????????????? ????
Other ox = (o1 + o1, o3 = o2 + o1);
// ------------------
cout << ox.i << endl;

return 0;
}

[Michael DOUBEZ]

red floyd a écrit :

josh wrote:

>On 13 Mar, 04:28, red floyd <no.s...@here.d udewrote:

>>Adrian Hawryluk wrote:
Old Wolf wrote:
To answer OP's question: the behaviour is unspecified because
overloade d comma operator does not retain the ordering of the
builtin comma operator. What's happening in this case is that
(o3 = o2 + o1) is being executed, and then (o1 + o1), and then
the overloaded comma operator is called with both of those results.
A different compiler might evaluate (o1 + o1) first, resulting in
o5 == 6.
So does that mean that the comma operator's evaluation order of left to
right is not implemented correctly on the compiler? I thought that it
was defined as left to right.
It is, if you don't overload it. If you overload it, then the
evaluation order is undefined, as I understand it. Similarly, if you
overload && or ||, the "short-circuit" behavior does not occur.

have you read it on the 14482 iso spec.?

I believe so. I'm at home right now, and my copy of 14882 is at work,
so it'll have to wait, unless other posters wish to comment on that.

[1.9/18] The POD &&, ||, ?: and , define a sequence.
In footnote (12) of the paragraph, it is specified that when those
operators are overloaded, they designate a function and "the operand
form an argument list without an implied sequence point between them".
Michael

[josh]

On 14 Mar, 10:16, Michael DOUBEZ <michael.dou... @free.frwrote:

red floyd a écrit :

josh wrote:

On 13 Mar, 04:28, red floyd <no.s...@here.d udewrote:
Adrian Hawryluk wrote:
Old Wolf wrote:
To answer OP's question: the behaviour is unspecified because
overloaded comma operator does not retain the ordering of the
builtin comma operator. What's happening in this case is that
(o3 = o2 + o1) is being executed, and then (o1 + o1), and then
the overloaded comma operator is called with both of those results.
A different compiler might evaluate (o1 + o1) first, resulting in
o5 == 6.
So does that mean that the comma operator's evaluation order of leftto
right is not implemented correctly on the compiler? I thought that it
was defined as left to right.
It is, if you don't overload it. If you overload it, then the
evaluation order is undefined, as I understand it. Similarly, if you
overload && or ||, the "short-circuit" behavior does not occur.
have you read it on the 14482 iso spec.?

I believe so. I'm at home right now, and my copy of 14882 is at work,
so it'll have to wait, unless other posters wish to comment on that.

[1.9/18] The POD &&, ||, ?: and , define a sequence.
In footnote (12) of the paragraph, it is specified that when those
operators are overloaded, they designate a function and "the operand
form an argument list without an implied sequence point between them".

Michael

so when am I overloading that operators the left-to-right sequence is
not implied (guaranted) and
if I have i.e. a && b && c (where a,b,c are object of a Type class
with that operators overloaded) is not evaluated first a && b and then
the result with c ???

[Michael DOUBEZ]

josh a écrit :

On 14 Mar, 10:16, Michael DOUBEZ <michael.dou... @free.frwrote:
[snip]

>[1.9/18] The POD &&, ||, ?: and , define a sequence.
In footnote (12) of the paragraph, it is specified that when those
operators are overloaded, they designate a function and "the operand
form an argument list without an implied sequence point between them".

so when am I overloading that operators the left-to-right sequence is
not implied (guaranted) and
if I have i.e. a && b && c (where a,b,c are object of a Type class
with that operators overloaded) is not evaluated first a && b and then
the result with c ???

No. Suposing the operator&& resolves to binary function, your expression
will be
operator&&(oper ator&&(a,b),c);

Then a,b and c will be evaluated in any order.

Michael

[josh]

On 14 Mar, 10:51, Michael DOUBEZ <michael.dou... @free.frwrote:

josh a écrit :

On 14 Mar, 10:16, Michael DOUBEZ <michael.dou... @free.frwrote:
[snip]

[1.9/18] The POD &&, ||, ?: and , define a sequence.
In footnote (12) of the paragraph, it is specified that when those
operators are overloaded, they designate a function and "the operand
form an argument list without an implied sequence point between them".

so when am I overloading that operators the left-to-right sequence is
not implied (guaranted) and
if I have i.e. a && b && c (where a,b,c are object of a Type class
with that operators overloaded) is not evaluated first a && b and then
the result with c ???

No. Suposing the operator&& resolves to binary function, your expression
will be
operator&&(oper ator&&(a,b),c);

Then a,b and c will be evaluated in any order.

Michael

yes but the calling function operator () came before any other
operator and in that case
will be logic if the compiler first called operator&&(a,b) and then
comapared the result with c

Josh

[Michael DOUBEZ]

josh a écrit :

On 14 Mar, 10:51, Michael DOUBEZ <michael.dou... @free.frwrote:

>josh a écrit :

>>On 14 Mar, 10:16, Michael DOUBEZ <michael.dou... @free.frwrote:
[snip]
[1.9/18] The POD &&, ||, ?: and , define a sequence.
In footnote (12) of the paragraph, it is specified that when those
operators are overloaded, they designate a function and "the operand
form an argument list without an implied sequence point between them".
so when am I overloading that operators the left-to-right sequence is
not implied (guaranted) and
if I have i.e. a && b && c (where a,b,c are object of a Type class
with that operators overloaded) is not evaluated first a && b and then
the result with c ???

No. Suposing the operator&& resolves to binary function, your expression
will be
operator&&(ope rator&&(a,b),c) ;

Then a,b and c will be evaluated in any order.

Michael

yes but the calling function operator () came before any other
operator and in that case
will be logic if the compiler first called operator&&(a,b) and then
comapared the result with c

Google for Sequence Point.

Michael

[Kai-Uwe Bux]

josh wrote:

>Precedence and arity do match. I have no idea, what you mean by
associativit y.

when I say about associativity I mean that if we have in an expression
more operators
of equal precedence i.e. * / % than it will be evaluated from left-to-
rigth
int a = 4 / 2 * 8 -first 4/2 and SECOND 2 * 8

I see. Note, however, that this provision does not reflect the evaluation
order in terms of which subexpressions get evaluated first. E.g.,

a + b - c * e

by left-to-right grouping for + and - is equivalent to

( a + b ) - ( c * e )

The compiler, however, is free to have c*e evaluated before a+b.

if I add to my class an overload of * and than I make i.e.
o1 + o2 * 03 the evaluation order is correct and in fact will be FIRST
o2 * o3 and SECOND

This is false: the evaluation order is unspecified. This is unrelated to
overloading. It is unspecified for built-in types, as well. See clause
[5/4].

This is not false! the evaluation order is the same of PDO. It is
unspecified
only if I have in an expression the same operators i.e.

Nope: in a*b-d/c it is unspecified whether a*b is evaluated before or after
d/c.

int a = 4 + 6 + b + f -here is not sure that the compiler goes from
left to right
it is guaranted only for && !! , ?: operators

Best

Kai-Uwe Bux

[josh]

Nope: in a*b-d/c it is unspecified whether a*b is evaluated before or after
d/c.

yes for a*b-d/c but we are speaking about more complex expressions
where
the order is: precedence and associativity but however I think that
the
comma operator when we overload it don't respect the PDO rules where
is guaranted the left-to-right evaluation (as && || and ?:)

Josh

[red floyd]

Michael DOUBEZ wrote:

red floyd a écrit :

[discussion on overloaded &&, ||, and ',' as sequence points redacted]

>>>

I believe so. I'm at home right now, and my copy of 14882 is at work,
so it'll have to wait, unless other posters wish to comment on that.

[1.9/18] The POD &&, ||, ?: and , define a sequence.
In footnote (12) of the paragraph, it is specified that when those
operators are overloaded, they designate a function and "the operand
form an argument list without an implied sequence point between them".

Thanks, Michael. I missed that one. I was looking at 13.6 and couldn't
find it.

[Kai-Uwe Bux]

josh wrote:

>

>Nope: in a*b-d/c it is unspecified whether a*b is evaluated before or
after d/c.

yes for a*b-d/c but we are speaking about more complex expressions
where
the order is: precedence and associativity but however I think that
the
comma operator when we overload it don't respect the PDO rules where
is guaranted the left-to-right evaluation (as && || and ?:)

Exactly, the overloaded comma-operator differs from the comma-operator for
POD types in this regard. And, I already said that:

Anyhow, what an overloaded comma operator lacks is the
sequence point that the built-in comma operator gives you.

Best

Kai-Uwe Bux

[Ron Natalie]

josh wrote:

>Nope: in a*b-d/c it is unspecified whether a*b is evaluated before or after
d/c.

yes for a*b-d/c but we are speaking about more complex expressions
where
the order is: precedence and associativity but however I think that
the
comma operator when we overload it don't respect the PDO rules where
is guaranted the left-to-right evaluation (as && || and ?:)

Precedence and associativity don't define order of operations.
Overloading operators changes neither of these.

Overloading operators ||, &&, and , does alter their LEFT
SIDE FIRST rule as well as in the case of the two formers
the REQUIRED omission of the evaluation of the second
operand if the first is true (for or) or false (for and).