Karl:

> If not, I would ask: How does one overload the comma operator while
> maintaining its attibutes as an operator?


It's of dubious usefulness but it can be done:

class thisclass
{ int&  operator,(int a); }

//To call this:  (thisclass)X, (int)Y ... (outside of arg-lists, of course)

This will return you an int, just as if the default comma operator had
executed.


In general, chain operators by returning references (Usually to the same
argument they took).

        Tom

--
The Tom spreads its huge, scaly wings and soars into the wild sky...
up...       up...     out of sight...   (tob@world.std.com)

In article <92255.154216KKEYTE@ESOC.BITNET>, KKEYTE@ESOC.BITNET (Karl Keyte) writes:
|> ...from a posting on 'comp.lang.c++'
|>
|> In article <1992Sep10.174914.838@taumet.com>, steve@taumet.com (Steve Clamage)
|> says:
|> >
|> 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

It seems to me that the ability to look at a comma expression and
infer some semantics from the syntax is a valuable aid
for program readability. This seems to me like an argument for
not permitting the comma operator to be overloaded. Of course,
the logical extension is to then forbid && and || from being
overloaded as well, but this seems unlikely to happen, unfortunately.

Daniel.Edelson@inria.fr

In article <BuH6sK.54r@world.std.com> tob@world.std.com (Tom O Breton) writes:
>Karl:
>
>> If not, I would ask: How does one overload the comma operator while
>> maintaining its attibutes as an operator?
>
>
>It's of dubious usefulness but it can be done:
>
>class thisclass
>{ int&  operator,(int a); }
>
>//To call this:  (thisclass)X, (int)Y ... (outside of arg-lists, of course)
>
>This will return you an int, just as if the default comma operator had
>executed.
> ...

Sorry, but you did not see what the problem is.
With an overloaded comma operator it is impossible to make sure
that the first operand (X) is _evaluated_ (completely) before
the second one, as is the case with the built-in operator.
Indeed, one would probably often like not to have the second operator
evaluated yet at all before the operator function is invoked.
This is important if either of the operands is an expression
with side effects (and with the built-in comma, you would not use
it at all unless the first operand really has side effects).

BTW, I regard it as a mistake to make comma (and '&') overloadable at all.
It is a clear breach of the principle: "C++ was designed to be
extensible, but not mutable".

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------

...from a posting on 'comp.lang.c++'

In article <1992Sep10.174914.838@taumet.com>, steve@taumet.com (Steve Clamage)
says:
>
>Karl Keyte <KKEYTE@ESOC.BITNET> 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