jimad@microsoft.UUCP (Jim ADCOCK) (01/22/91)
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?
jimad@microsoft.UUCP (Jim ADCOCK) (01/23/91)
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."
dag@control.lth.se (Dag Bruck) (01/23/91)
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.
sarima@tdatirv.UUCP (Stanley Friesen) (01/24/91)
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)
jimad@microsoft.UUCP (Jim ADCOCK) (01/30/91)
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."
sking@nowhere.uucp (Steven King) (02/03/91)
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...
lijewski@batcomputer.tn.cornell.edu (Mike Lijewski) (02/04/91)
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
jimad@microsoft.UUCP (Jim ADCOCK) (02/05/91)
|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.