🚀 go-pugleaf

|In article <1991Feb02.165526.1933@nowhere.uucp> sking@nowhere.uucp (Steven King) writes:
|In article <70305@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
|>"An operator function must either be a member function or take at least one
|>argument of class type, enum type,  or of a type derived from a class 
|>or enum type."
|
|   There are is a problem with allowing operator overloading, or even
| operators at all, on enums. Given 
|
| enum modes { rd_ok = 1, wr_ok = 2, ex_ok = 4 } ;
|
| for ( modes m = rd_ok ; m < ex_ok ; m++ ) // this is accepted by Cfront 2.0!
|
|   What does _m++_ do? The problem with arbitrary arithmatic manipulations
| of enum's are alluded to in ARM ( sorry, dont have the # ).

This is no different that the traditional argument against operator
overloading in C++.  That fact that operator overloading can be applied
in the wrong places, or in silly manners, doesn't mean that operator
overloading is bad.  Conversely, C++ provides the features, and assumes
that the C++ programmer is mature enough to use them wisely.  Consider
the following counter-example:

enum stoplight_color { green = 1, yellow = 2, red = 3 };

// [ alternative declaration syntaxes might be better than this: ]
stoplight_color operator++(stoplight_color c, int dummy_parm)
{
	switch (c)
	{
	case green:  return yellow;
	case yellow: return red;
	case red:    return green;
	}
}

which implements the standard stoplight color sequence.

Also, consider the case of a Double class as today permitted by C++.
What would be the "appropriate" meaning of op++ applied to such a class?

Or, consider the already-permitted use of a friend function, say unary op&,
to "hijack" the operation of a struct.