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