🚀 go-pugleaf

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