home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / cplus / 896 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  3.5 KB

  1. Path: sparky!uunet!lhdsy1!kato.lahabra.chevron.com!hwrvo
  2. From: hwrvo@kato.lahabra.chevron.com (W.R. Volz)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: New operators wish list
  5. Message-ID: <5248@lhdsy1.lahabra.chevron.com>
  6. Date: 21 Jul 92 16:18:10 GMT
  7. References: <658@manutius.UUCP>
  8. Sender: news@lhdsy1.lahabra.chevron.com
  9. Organization: Chevron Oil Field Research Company
  10. Lines: 80
  11.  
  12. In article <658@manutius.UUCP>, garyp@manutius.UUCP (Gary Powell) writes:
  13. |> Ok, Ok Ok...lets cut the relgion and get to the meat of the matter.
  14. |> 
  15. |> It appears to me that there are a large number of folks who want the following
  16. |> new operators added to the language.
  17. |> 
  18. |> 1) ||=
  19. |> 
  20. |>    where:  x ||= y   <==>  x = x || y
  21. |> 
  22. |>    Seems resonable as it matches all the "Blah"= operators.
  23. |> 
  24. |> 2) &&=
  25. |> 
  26. |>    where:  x &&= y   <==>  x = x && y
  27. |> 
  28. |>    Also seems reasonable for the same issue as #1.
  29. |> 
  30. |> 
  31. |> 3) ===
  32. |> 
  33. |>    where x === y   <==> x = x == y
  34. |> 
  35. |>    I have more trouble looking at this one, but again it still fits the
  36. |>    "blah"= operator rule.  So it maybe that I just haven't thought about
  37. |>    it long enough. Anyway I recommend it.
  38. |>   
  39. |> 4) some set of chars yet to be determined which bind tighter than the * and /
  40. |>    for which x power y  is x raised to the power of y.
  41. |> 
  42. |>    This seems reasonable but again has the problem of what do we do with
  43. |>    the odd ball arguments of y and x?
  44. |> 
  45. |>    I recommend we define it as an operator but leave its implementation alone
  46. |>    and let everyone overload it as they see fit. And I don't care which
  47. |>    set or single character is chosen. My reasoning is that the current
  48. |>    arguments don't seem to be converging.  Maybe someone else (I'm sure I'll
  49. |>    see heat on this one.) would care to summarize the arguments on this.
  50. |> 
  51. |> 5) "."
  52. |>    Lets add this.  I mean really, no one's code will break if we have it,
  53. |>    the earth will not shake and the sky fall down.  If it turns out to be
  54. |>    not as useful as Jim claims..so what?  We'll drop it from language "D"
  55. |>    the next generation.
  56. |> 
  57. |> Any others I've missed???
  58. |> 
  59. |> Lets get on with it.  Like it or not many of us have to work with C++ even
  60. |> though language "X" is better at some other task.  Lets add the features folks
  61. |> clamor for.  IF they can make a convincing statement of "It won't break any
  62. |> existing code. And it is possible for someone of resonable experience 
  63. |> programming to use it without shooting themselves in the foot."
  64. |> 
  65. |> We still have a lot of other pressing problems, like how to incorporate 
  66. |> persistance, and how to do good garbage collection, and how to at run time
  67. |> create objects whose type isn't known until after the program is running.
  68. |> 
  69. |> 
  70. |> BTW.
  71. |>   Could you folks who want to argue language issues move your discussion over
  72. |> to this group?  Then we can quit annoying the folks who want to compare
  73. |> Borland to Mircosoft or ask the beginners questions. And I don't have
  74. |> to read 100 or more messages to find the language issue ones.
  75. |> 
  76.  
  77. Whoa. All of these are simply programmer convienences (sp?). I would rather
  78. code a few more characters and be able to clearly read the code than save a few
  79. bytes of disk space. If that many new operators are going to be added, 
  80. why not just make it a rule for all binary operators? 
  81.  
  82. .i.e, x (op)= y;  <==>   x = x (op) y;
  83.  
  84. -- 
  85.  
  86. ======================
  87. Bill Volz
  88. Chevron Oil Field Research Co.
  89. Exploration Research/Geophysics Division.
  90. P.O. Box 446, La Habra, CA 90633-0446
  91. Phone: (310) 694-9340
  92.