home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / cplus / 1185 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  2.5 KB
  1. Xref: sparky comp.std.c++:1185 comp.lang.c++:13673
  2. Newsgroups: comp.std.c++,comp.lang.c++
  3. Path: sparky!uunet!wupost!m.cs.uiuc.edu!sunb10.cs.uiuc.edu!sparc10.cs.uiuc.edu!pjl
  4. From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
  5. Subject: Re: Exponentiation operator proposal
  6. Message-ID: <1992Sep15.140027.17387@sunb10.cs.uiuc.edu>
  7. Sender: news@sunb10.cs.uiuc.edu
  8. Organization: University of Illinois at Urbana-Champaign
  9. References: <23660@alice.att.com> <HBF.92Sep14205333@durin.uio.no> <1992Sep15.054226.4126@cc.tut.fi>
  10. Date: Tue, 15 Sep 1992 14:00:27 GMT
  11. Lines: 43
  12.  
  13. In <1992Sep15.054226.4126@cc.tut.fi> jk87377@cc.tut.fi (Juhana Kouhia) writes:
  14.  
  15. >Hi,
  16.  
  17. >I'm very new in C++ world; I have not done any programs so far;
  18. >and I'm currently reading C++ Primer books on chapter 3   :-)
  19.  
  20. >Instead of making exponential operator; I would like to get
  21. >a new basic operation which allows programmer to define new
  22. >operations like 'a ** b'; that is, the '**' is defined.
  23. >('a pow b' is also good.)
  24.  
  25. *****>    The short answer is that it's a _real_ pain.  The somewhat
  26.     longer answer is that making new operators means that you have
  27.     to also establish the precedence and associativity of the new
  28.     operator relative to all the other operators *AND* any other
  29.     operators created by other people.  Every time an operator is
  30.     added, the hierarchy would have to be readjusted.
  31.  
  32.     For new operators, the precedence and associativity may seem
  33.     arbitary at the time of creation, but it may later be realised,
  34.     after experience, that it could have been done better...of
  35.     course it's too late to change it now because code would break.
  36.  
  37.     Also, if you were to use library X and library Y, each could use
  38.     the same operator for different reasons, and the two operators
  39.     were developed without regard to the others precedence and
  40.     associativity; how would the compiler resolve this?  (I'm not
  41.     looking for people to show how smart they are here by telling me
  42.     how a compiler could resolve this...the point is that even if
  43.     the compiler could do it, most _people_ would have a tough time
  44.     looking at the code.)
  45.  
  46.     It's more trouble than its worth.  The _point_ of operator
  47.     overloading is to give an operator a _natural_ extension to
  48.     another type.  People shouldn't sit around trying to figure out
  49.     how to force an operator (square peg) to be used for a new type
  50.     (round hole).  If the operator's use in a new context isn't
  51.     intuitively obvious, forget it and use function-notation.
  52. -- 
  53.     - Paul J. Lucas                University of Illinois    
  54.       AT&T Bell Laboratories        at Urbana-Champaign
  55.       Naperville, IL            pjl@cs.uiuc.edu
  56.