home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / alt / msdos / programm / 3130 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  3.3 KB
  1. Xref: sparky alt.msdos.programmer:3130 comp.os.msdos.programmer:11980 comp.sys.ibm.pc.programmer:767 comp.lang.c++:18934 comp.lang.c:19531
  2. Path: sparky!uunet!cs.utexas.edu!rutgers!att-out!cbnewsj!davet
  3. From: davet@cbnewsj.cb.att.com (Dave Tutelman)
  4. Newsgroups: alt.msdos.programmer,comp.os.msdos.programmer,comp.sys.ibm.pc.programmer,comp.lang.c++,comp.lang.c
  5. Subject: Re: Newbie Wants Advice on C-Programming
  6. Message-ID: <1993Jan11.131838.12844@cbnewsj.cb.att.com>
  7. Date: 11 Jan 93 13:18:38 GMT
  8. References: <FISCHER.92Dec30223532@orange.iesd.auc.dk> <1992Dec31.043002.24014@ucc.su.OZ.AU> <FISCHER.93Jan9030817@orange.iesd.auc.dk>
  9. Organization: AT&T Bell Labs - Lincroft, NJ
  10. Lines: 59
  11.  
  12. In article <FISCHER.93Jan9030817@orange.iesd.auc.dk> fischer@iesd.auc.dk (Lars Peter Fischer) writes:
  13. >
  14. >>>>>> "Michael" == Michael Malak (malak@grebyn.com)
  15. >>>>>> "Lars" == fischer@iesd.auc.dk (Lars Peter Fischer)
  16. >>>>>> "John" == John MAX Skaller (maxtal@extro.ucc.su.OZ.AU)
  17. >
  18. >Michael>    1) It has structured syntactic blocks for constants, types and
  19. >Michael>       variables.
  20. >...
  21. >John>     Seems to me that the simple concept of
  22. >John> nesting the symbol table so that symbols go out of scope at the
  23. >John> end of the block is very nice.
  24.  
  25. C and C++ have this, too.
  26.  
  27. >Lars>Ah, yes, but Pascal goes further. I says First we define all the
  28. >Lars>Types, then all the Variables, then all the Functions, and so on....
  29. >Lars>This is a real pain and
  30. >Lars>makes code for anything but toy programs very hard to read.
  31.  
  32. My organization's coding standard (adopted explicitly to make our software
  33. easier to read and maintain) calls for declaring and initializing
  34. variables as close as possible to their point of first use.  In the ability
  35. to meet this goal:
  36.     C++ good.
  37.     Pascal bad.
  38.  
  39. >John>     Dont quite agree. Many 'mess-arounds' in C could be avoided
  40. >John> if nested proceedures were supported. C's failure to provide them
  41. >John> possibly results from being designed with archaic architectures
  42. >John> in mind.
  43.  
  44. Don't see what this has to do with hardware architectures, if that's
  45. what you meant.  If "software architectures", I don't see any that
  46. Pascal supports and C++ doesn't; quite the contrary, actually.
  47. Perhaps you could elaborate.
  48.  
  49. As someone who has a few years real-world programming experience with
  50. each of C and Pascal, the ONLY times I've ever wished for nested
  51. procedures in C involved a combination of:
  52.  - Repetitive operations of the same pattern within a single function,
  53.    that weren't repeated in any other function.
  54.  - A lot of function-specific state information (i.e.- local variables)
  55.    required for this operation... too many to make each one an argument
  56.    of a procedure.
  57.  
  58. In such cases, I use macros in C; not as elegant as nested procedures,
  59. but they do the job.
  60.  
  61. I tend to trip over this about once every couple of dozen source files.
  62. The operation is never something significant to the functional decomposition
  63. of my design, just a convenience for a few pages of code.  I've never
  64. encountered a difficulty in either functional or data decomposition that
  65. really mattered to my design, where C didn't solve it at least as well
  66. as Pascal.  And I find that C++ provides the best safety features of Pascal
  67. (tight type checking) without the unnecessary and ugly restrictions that
  68. have led me to drop Pascal in those applications where I have a choice.
  69.  
  70. Dave
  71.