home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / cplus / 1186 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  1.9 KB
  1. Xref: sparky comp.std.c++:1186 comp.lang.c++:13678
  2. Newsgroups: comp.std.c++,comp.lang.c++
  3. Path: sparky!uunet!utcsri!torn!cunews!nrcnet0!bnrgate!bcrka451!bcrki65!sjm
  4. From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
  5. Subject: Re: Exponentiation operator proposal
  6. Message-ID: <1992Sep15.141940.12960@bcrka451.bnr.ca>
  7. Sender: 5E00 Corkstown News Server
  8. Organization: Bell-Northern Research Ltd., Ottawa, Canada
  9. References: <1992Sep13.193507.27813@ima.isc.com> <BuJJxs.8Hx@world.std.com> <23663@alice.att.com>
  10. Date: Tue, 15 Sep 1992 14:19:40 GMT
  11. Lines: 36
  12.  
  13. In article <23663@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
  14. >How frequent is a**p anyway? (has anyone got any data?)
  15.  
  16. I always avoid ** when I mean a mixture of multiplication and dereference
  17. (in C).  I use parentheses to make it clear what is dereference and what
  18. is multiplication.  Thus I would always write:  a * (*p)
  19.  
  20. Or, in the case of a***p, I would write:  a * (**p)
  21.  
  22. There are two situations where I might have generated a**p accidentally:
  23.  
  24. 1.  #define THE_VALUE *p  /* This is C code.  Should be (*p) anyway */
  25.  
  26.     a*THE_VALUE
  27.  
  28. 2.  a*i
  29.     global change of i to *p
  30.  
  31.  
  32. Case 1 should not show up in C++ code and is poor style in C code
  33. because of the missing parentheses in the #define.
  34.  
  35. Case 2 should be a global change to (*p) anyway because of the
  36. danger of a/i being changed to a/*p  (comment!)
  37.  
  38. So no, I do not intentionally generate code of the problem form.
  39. I have seen such code, but only in code that I consider a nightmare
  40. to read and maintain anyway.  Keep in mind also that I know of the
  41. "global change results in comment" problem, so that means there must
  42. be some a**p code around here generated that way.
  43.  
  44. Stuart
  45. --
  46. : Stuart MacMartin                                    email: sjm@bnr.ca      :
  47. : Bell-Northern Research                              phone: (613) 763-5625  :
  48. : PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
  49.