home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / cplus / 1177 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  3.1 KB
  1. Xref: sparky comp.std.c++:1177 comp.lang.c++:13622
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!agate!ohm.berkeley.edu!jbuck
  3. From: jbuck@ohm.berkeley.edu (Joe Buck)
  4. Newsgroups: comp.std.c++,comp.lang.c++
  5. Subject: Re: Exponentiation operator proposal
  6. Date: 14 Sep 1992 17:30:30 GMT
  7. Organization: U. C. Berkeley
  8. Lines: 61
  9. Message-ID: <192i7mINN80e@agate.berkeley.edu>
  10. References: <1992Sep13.193507.27813@ima.isc.com> <BuJJxs.8Hx@world.std.com> <23663@alice.att.com>
  11. NNTP-Posting-Host: ohm.berkeley.edu
  12.  
  13.  
  14. >How frequent is a**p anyway? (has anyone got any data?) How confusing
  15. >would it really be? Many people use spaces to clarify (to their eyes,
  16. >if not to everyone else's) code, e.g. a * *p. Also, not all overloading
  17. >creates confusion, especially when identifier names are chosen with
  18. >a minimum of care (want would x**e mean? a**xptr mean?). I doubt the
  19. >case is clear cut.
  20.  
  21. About the most frequent operation in digital signal processing is some
  22. form of the dot product.  Consider
  23.  
  24. double dotProduct(double *x, double *y, int n) {
  25.     double sum = 0.0;
  26.     while (--n >= 0) sum += *x++ * *y++;
  27.     return sum;
  28. }
  29.  
  30. I guarantee (as someone who's written a large amount of numerical C
  31. and C++ code) that there is a great deal of code of the above type,
  32. and while I'm generally careful to space it as above, I've seen code
  33. that doesn't have this spacing.
  34.  
  35. You'd break programs, no ifs, ands, or buts about it.  It's true that
  36. this breakage would be detected at compile time (the right argument to
  37. '**' would be a pointer).
  38.  
  39. As Dr. Stroustrup suggested, an alternative would be to have '*' '*'
  40. mean exponentiation and handle x '*' '*' ptr as a special case, so
  41. it would keep its meaning of dereference-and-multiply.  That would
  42. work, as best I can tell, for C, but in C++, '*' might be overloaded
  43. for the unary or binary case.  This hack wouldn't work then or would
  44. cause nasty surprises.
  45.  
  46. I think Matt Austern's analysis is basically correct: the exponentiation
  47. operator should be a token, one not appearing in the language currently
  48. so that it cannot break existing programs.  Those in favor of ** must
  49. show, IMHO, that it would break virtually no programs, and this can't
  50. be done without introducing a series of hacks.  If every other language
  51. used **, this would be a strong argument in its favor, but many languages
  52. use ^ instead.
  53.  
  54. Furthermore, there are three other considerations: the ability to construct
  55. the corresponding assignment operator (eliminating !), the
  56. internationalization issues (eliminating several characters like @ that
  57. aren't on all keyboards), and avoiding breaking analogies between
  58. operators (there is a relation between & and &&, and | and ||, which
  59. should not be violated for ^ and ^^).
  60.  
  61. >I am not arguing that ** is THE right solution, but that given the
  62. >demand for it and the lack of ginuinely nice alternatives ** should
  63. >not be written off without a thought and/or in the belief that it
  64. >is technically infeasible to provide it.
  65.  
  66. Before Fortran, no one thought ** should mean exponentiation.  Any
  67. reasonable token choice that doesn't violate one of the above
  68. considerations will work.  Austern's *^ is as good as any.
  69.  
  70.  
  71.  
  72. --
  73. Joe Buck    jbuck@ohm.berkeley.edu
  74.