|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.

Is there any good reason why the restriction in 13.4

"An operator function must either be a member function or take at least one
argument of a class or a reference to a class."

shouldn't be [clarified and] relaxed to:

"An operator function must either be a member function or take at least one
argument of class type or of a type derived from a class type."

This change would increase programming freedom while maintaining the
original intent of preventing operators on built-in types or their
derivatives from being overloaded.

Comments?

In article <21@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 or of a type derived from a class type."

This statement seems to have confused some people -- I meant "derived type"
when I said "derived type" -- not derived class.  See page 24 of ARM for
a description of "derived types."  Given a class foo, a foo*, a foo&, a
foo**, a foo[100] ... are all "derived types."

In article <35@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>In article <21@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 or of a type derived from a class type."

I understand why you would not allow the user to redefine operators on
built-in types, e.g., "int + int".

Operator functions acting on enumerations -- in addition to classes --
would be useful, though.

Do we really need the restriction Jim quoted from the ARM?  If we
tried to redefine "int + int", wouldn't a "multiple definition of
operator+(int,int)" be enough to tell us that we did a no-no?

  -- Dag B.

In article <21@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
|Is there any good reason why the restriction in 13.4
|
|"An operator function must either be a member function or take at least one
|argument of a class or a reference to a class."
|
|shouldn't be [clarified and] relaxed to:
|
|"An operator function must either be a member function or take at least one
|argument of class type or of a type derived from a class type."

I'm not sure I see the difference.  A type derived from a class type is also
a class type!  The only real difference I see is that your proposed new version
forgets to allow references, and is thus *more* restrictive.
--
---------------
uunet!tdatirv!sarima    (Stanley Friesen)

In article <95@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes:
|In article <21@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 or of a type derived from a class type."
|
|I'm not sure I see the difference.  A type derived from a class type is also
|a class type!  The only real difference I see is that your proposed new version
|forgets to allow references, and is thus *more* restrictive.

Again, please don't confuse class derivation with type derivation.  Class
derivation is only one way to make derived types.  See page 24 ARM for
a number of other ways to make derived types.  Also, it has been pointed
out to me that now that enums are distinct types, perhaps they too should
be candidates for operator overloading:

"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."

In article <70305@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>
>a number of other ways to make derived types.  Also, it has been pointed
>out to me that now that enums are distinct types, perhaps they too should
>be candidates for operator overloading:
>
>"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 # ).

--
                                        ..!cs.utexas.edu!ut-emx!nowhere!sking

been dazed and confused for so long its true; wanted an OS, never bargined for
you. Lotsa people hacking, few of them know, kernal of unix was created below...

In article <1991Feb02.165526.1933@nowhere.uucp> sking@nowhere.uucp (Steven King) writes:
>In article <70305@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>>
>>a number of other ways to make derived types.  Also, it has been pointed
>>out to me that now that enums are distinct types, perhaps they too should
>>be candidates for operator overloading:
>>
>>"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 # ).

It is a bug that m++ is accepted.  In a ARM-conforming C++ implementation
this would be a bug since what you have is

  m = (int)(m + 1);

and integers cannot be assigned to enums.

>
>--
>                                        ..!cs.utexas.edu!ut-emx!nowhere!sking
>
>been dazed and confused for so long its true; wanted an OS, never bargined for
>you. Lotsa people hacking, few of them know, kernal of unix was created below...


--
Mike Lijewski  (H)607/272-0238 (W)607/254-8686
Cornell National Supercomputer Facility
ARPA: mjlx@eagle.cnsf.cornell.edu  BITNET: mjlx@cornellf.bitnet
SMAIL:  25 Renwick Heights Road, Ithaca, NY  14850