NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/cplus/13642

Internet Message Format | 1992-09-14 | 3.3 KB

Path: sparky!uunet!wupost!swbatl!texbell!swuts!sw1sta!sg3235
From: [e-mail] (Stephen Gevers)
Newsgroups: comp.lang.c++
Subject: Re: Answers on a postcard...
Message-ID: <[e-mail]>
Date: 14 Sep 92 13:25:31 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Southwestern Bell
Lines: 67

In article <[e-mail]> [e-mail] (Karl Keyte) writes:
]In article <[e-mail]>, [e-mail] (Steve Clamage)
]says:
]>
]>Karl Keyte <[e-mail]> writes:
]>
]>|#include <iostream.h>
]>
]>|class X {
]>|   private:    int           value;
]>|   public:     int           operator , (int i) { return i+10; };
]>|               int           operator + (int i) { return value+i; };
]>|               X &           operator = (int i) { value=i; return *this; };
]>|};
]>
]>
]>|void main()
]>|{
]>|   X         x;
]>
]>|   cout << "Value is " << (x=1, x+1) << endl;
]>|}
]>
]>In the expression in parens, it is unspecified whether "x=1" or
]>"x+1" is evaluated first.  They are arguments to the "operator,()"
]>function, not the left and right side of a comma-expression.  If
]>"x+1" is evaluated first, which is legal, it will use an
]>uninitialized "x.value".
]>
]>Don't write code which depends on unspecified order of evaluation.
]>
]>If there were no "op,()", the "," would mark a comma-expression,
]>and the "x=1" would have to be evaluated first; in that case the
]>whole expression would be well-defined.
]
]The implication of what you say is that it is not possible to overload
]operators maintaining the correct functionality of the operator.  This
]indeed means that precedence in overloaded operators cannot be maintained
]if all operands are simply passed as arguments to the function implementing
]the operator functionality and evaluated in a language independent order.
]Imagine commonly used "chain" operators such as && and ::.
]
]If what is described above is correct, and Mr.Clamage clearly has much
]experience in the area, then I think we have justification for pressing
]for a change in this area.  If not, I would ask: How does one overload
]the comma operator while maintaining its attibutes as an operator?
]
]Karl

While I understand Mr. Clamage's explanation, I do not see any support of it
in the ARM.  Specifically, section 5.18 states "A pair of expressions separated
by a comma is evaluated left-to-right and the value of the left expression is
discarded.  All side effects of the left expression are performed before the
evaluation of the right expression."  Section 5 states "Operator overloading
cannot modify the rules for operators applied to types for which they are
defined by the language itself."  Finally, the commentary in section 13.4 says
"In particular, overloaded operators , and ->* obey exactly the same rules as
other overloaded binary operators, such as ^ and %."

I have the 1st edition of the ARM and I don't know if there is any more
specific reference to the comma operator in the second edition.  I tested the
above code on Borland C++ 3.0 and Cfront 2.0.  Borland gave a result in the
high 6000's and Cfront gave the result of 12.  BTW, has anyone really used the
comma operator for something useful???

Stephen Gevers
sw1sta.sbc.com