home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13619 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  3.3 KB
  1. Path: sparky!uunet!noc.near.net!hri.com!ukma!netnews.louisville.edu!starbase.spd.louisville.edu!aldavi01
  2. From: aldavi01@romulus.spd.louisville.edu (Arlie Davis)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Answers on a postcard...
  5. Message-ID: <aldavi01.716489561@starbase.spd.louisville.edu>
  6. Date: 14 Sep 92 16:52:41 GMT
  7. References: <1992Sep11.174716.3699@taumet.com> <92256.150512KKEYTE@ESOC.BITNET> <1992Sep13.160033.7735@taumet.com> <1992Sep13.204500.16311@tfs.com>
  8. Sender: news@netnews.louisville.edu (Netnews)
  9. Organization: University of Louisville
  10. Lines: 52
  11. Nntp-Posting-Host: romulus.spd.louisville.edu
  12.  
  13. In <1992Sep13.204500.16311@tfs.com> eric@tfs.com (Eric Smith) writes:
  14.  
  15. > In article <1992Sep13.160033.7735@taumet.com> steve@taumet.com (Steve Clamage) writes:
  16. > ...
  17. > >It would be possible to change the rules so that order of evaluation
  18. > >was preserved for overloaded versions of operators "&&", "||", and ",".
  19. > >Any proposal to do so would have to show some good reason why the
  20.  
  21. > Why not just require all function arguments to always be evaluated left
  22. > to right?  That would simplify the language, shorten its description,
  23. > make it easier for novices to learn, and would not break any existing
  24. > bug-free code.  I never did understand the value of leaving such
  25. > questions open, which accomplishes nothing useful and makes bugs
  26. > behave differently with different compilers.
  27.  
  28. NO.  From what I understand, the things in the ANSI C standard and in
  29. the ARM that are left undefined are done so to allow different
  30. architectures to compile and run C in the fastest / best manner
  31. possible, while still conforming to the standard.
  32.  
  33. If you require / define something, such as the sequence of evaluation
  34. for parameters of a function call, you potentially require some
  35. compiler X for some machine Y to go to extremes in order to remain
  36. conformant with the standard.  With the problem above, you might have
  37. one environment in which function calls were fastest when the
  38. first parameters were pushed first, but on another machine with a
  39. completely different environment pushing the last parameters first
  40. makes the most sense.  (I have never heard of an environment which
  41. evaluates / pushes function args in forward order, but who knows.)
  42. On some architectures, function arguments may be evaluated
  43. simultaneously!
  44.  
  45. So, if you rigidly define the sequence of evaluation, you potentially
  46. wound many C compilers + architectures.  Same goes for many other
  47. things that are marked "undefined" or "architecture dependent".
  48. (I remember a debate on the remainder operator, in which some people
  49. wanted to define the result of the remainder operator for negative
  50. operands.  Someone pointed out that the native assembler instruction
  51. for remainder varies from architecture to architecture, and that
  52. requiring all C compilers to return the same value for negative
  53. operands for remainder would mean that *many* compilers would have to
  54. generate many more opcodes in order to satisfy the standard.)
  55.  
  56. Even if all the architectures that we *ever* used did everything in
  57. the same way ( ;) ), I would still want some of the things in ANSI C
  58. / the ARM left undefined, because relying on them encourages poor
  59. programming practice, in my opinion.  Example: Using post-increment
  60. on the same variable twice in the same expression.
  61.  
  62.  
  63. -- 
  64. lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null
  65.