home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / cplus / 1176 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  2.6 KB
  1. Xref: sparky comp.std.c++:1176 comp.lang.c++:13607
  2. Path: sparky!uunet!sun-barr!cs.utexas.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!allegra!alice!bs
  3. From: bs@alice.att.com (Bjarne Stroustrup)
  4. Newsgroups: comp.std.c++,comp.lang.c++
  5. Subject: Re: Exponentiation operator proposal
  6. Message-ID: <23663@alice.att.com>
  7. Date: 14 Sep 92 14:27:49 GMT
  8. Article-I.D.: alice.23663
  9. References: <23660@alice.att.com> <1992Sep13.193507.27813@ima.isc.com> <BuJJxs.8Hx@world.std.com>
  10. Organization: AT&T Bell Laboratories, Murray Hill NJ
  11. Lines: 47
  12.  
  13.  
  14.  
  15. karl@ima.isc.com (Karl Heuer) writes
  16.  
  17.  > >(2) I think we could actually get ** as the exponentiation operator.
  18.  > >[By defining `**' to have semantics of TIMES FETCH when the right operand
  19.  > >is a pointer]
  20.  
  21.  > I considered this when I wrote my exponentiation essay.  I decided that it
  22.  > might be possible, but it's way too confusing!  This would be a kludge of the
  23.  > highest order.  It's much better to use syntax that's not already taken --
  24.  > I've adopted "*^", as suggested by someone else some years ago.  (A hybrid of
  25.  > "**" and "^", sort of.)
  26.  
  27. Of course it is a hack. It is a compatibility hack of the first order,
  28. but I see few TECHNICAL problems with it.
  29.  
  30. and  rr@world.std.com (Robert I Ransbottom) writes
  31.  
  32.  > I agree ** is confusing, given the potential frequency of both "dat**ptr" and
  33.  > "dat**dat" it seems like a waste to deciphering such.  The proponents
  34.  > of **expon want a convenience. 
  35.  > 
  36.  > I think that ^^ would be more satisfying to both pointer-ers and math-ers.  
  37.  > 
  38.  >     1. Its not already taken!
  39.  >     .   .   .    .      .
  40.  >     n. Its easier to type than Karl's *^. 
  41.  
  42. The reason I mentioned ** is that I think that every alternative mentioned
  43. so far has something wrong with it. I see ^ as xor and ^^ bothers me.
  44. As it happens *^ doesn't bother me but my feeling was that 99% of the
  45. deamand for an exponentiation operator comes from current or past Fortran
  46. users and - in my experience - they always ask for ** and are unsatisfied
  47. with the explanations of why they can't have that syntax.
  48.  
  49. How frequent is a**p anyway? (has anyone got any data?) How confusing
  50. would it really be? Many people use spaces to clarify (to their eyes,
  51. if not to everyone else's) code, e.g. a * *p. Also, not all overloading
  52. creates confusion, especially when identifier names are chosen with
  53. a minimum of care (want would x**e mean? a**xptr mean?). I doubt the
  54. case is clear cut.
  55.  
  56. I am not arguing that ** is THE right solution, but that given the
  57. demand for it and the lack of ginuinely nice alternatives ** should
  58. not be written off without a thought and/or in the belief that it
  59. is technically infeasible to provide it.
  60.