home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / alt / msdos / programm / 3122 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  4.8 KB
  1. Xref: sparky alt.msdos.programmer:3122 comp.os.msdos.programmer:11935 comp.sys.ibm.pc.programmer:757 comp.lang.c++:18866 comp.lang.c:19460
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!think.com!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!dkuug!aud.dk!vaxc.aud.auc.dk!fischer
  3. From: fischer@iesd.auc.dk (Lars Peter Fischer)
  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: <FISCHER.93Jan9030817@orange.iesd.auc.dk>
  7. Date: 9 Jan 93 02:08:17 GMT
  8. References: <1hdpluINN1lv@agate.berkeley.edu>
  9.     <1992Dec25.070024.15672@grebyn.com>
  10.     <FISCHER.92Dec30223532@orange.iesd.auc.dk>
  11.     <1992Dec31.043002.24014@ucc.su.OZ.AU>
  12. Sender: news@vaxc.aud.auc.dk (USENET News System)
  13. Organization: Mathematics and Computer Science, Aalborg University
  14. Lines: 86
  15. In-Reply-To: maxtal@extro.ucc.su.OZ.AU's message of Thu, 31 Dec 1992 04: 30:02 GMT
  16.  
  17.  
  18. >>>>> "Michael" == Michael Malak (malak@grebyn.com)
  19. >>>>> "Lars" == fischer@iesd.auc.dk (Lars Peter Fischer)
  20. >>>>> "John" == John MAX Skaller (maxtal@extro.ucc.su.OZ.AU)
  21.  
  22. Michael>    1) It has structured syntactic blocks for constants, types and
  23. Michael>       variables.
  24.  
  25. Lars> Which is not much of an advantage. Look at all the pain Knuth has gone
  26. Lars> through to work around it.
  27.  
  28. John>     Could you explain? Seems to me that the simple concept of
  29. John> nesting the symbol table so that symbols go out of scope at the
  30. John> end of the block is very nice.
  31.  
  32. Ah, yes, but Pascal goes further. I says First we define all the
  33. Types, then all the Variables, then all the Functions, and so on. This
  34. is a pain because it forces you to write type definition here,
  35. variable declarations there, and the functions that manipulate
  36. variables of the types somewhere else again. This is a real pain and
  37. makes code for anything but toy programs very hard to read.
  38.  
  39. Contrast with the ability in C to group functions, variables and types
  40. as appropriate, in separate compilation units if desired.
  41.  
  42. Knuth ended up inventing WEB in part to solve these problems, and so
  43. we might see this particular Pascal deficiency as an advantage, since
  44. WEB truly enriches the toolchest of the programmer.
  45.  
  46. John>     Dont quite agree. Many 'mess-arounds' in C could be avoided
  47. John> if nested proceedures were supported. C's failure to provide them
  48. John> possibly results from being designed with archaic architectures
  49. John> in mind.
  50.  
  51. Which mess-arounds are we talking about here? I don't get the
  52. architecture bit -- why would nesting functions be dependent on the
  53. architecture of the hardware used.
  54.  
  55. John>     Functional decomposition is a valid technique in my opinion.
  56. John> So is partitioning the state space with objects. Forcing the programmer
  57. John> to use data decomposition because functional decomposition is not
  58. John> properly supported is against the spirit of C++ in my opinion.
  59.  
  60. Sure. There's no reason you can't use functional decomposition in C.
  61. The question is, will nested functions make it simpler to do? I find
  62. it much more useful to simply hide detail in compilation modules, and
  63. I can't see that writing function A inside function B is any help as
  64. compared to having A be a module-private function living in the same
  65. space as B. The chance that A is not ever going to be used from
  66. anywhere but from B is often slim, and it makes for some strange
  67. structures when some functions are nested while others are moved up
  68. because they are used from to places.
  69.  
  70. Nah, nested *classes* is what's important to the spirit of C++.
  71. Happily we have that now. If we could just have virtual classes, we'd
  72. be almost there.
  73.  
  74. John>     But C cannot be used easily for functional decomposition
  75. John> because it doesn't provide proper support for nested functions.
  76. John> Structured design may not be tied to a specific language,
  77. John> but structured programming in a structured language is certainly
  78. John> easier than in a non-structured one. 
  79.  
  80. Again, I don't agree that you cannot do functional decomposition if
  81. you do not have nested functions, and I most certainly do not agree
  82. that C is not a structured language. 
  83.  
  84. I've done my deal of Pascal programming, and once I got hold of a
  85. version that supported separated compilation units I don't think I
  86. really found much use for nested functions again.
  87.  
  88. Functional decomposition is seldom used in such a pure form that it is
  89. not mixed with a module concept and with identification of data
  90. structures, and such that the decomposition results in a tree and not
  91. DAG.
  92.  
  93. John> Do you really want to write code in the old BASIC (you know, the
  94. John> one with line numbers and GOSUB without parameters?)
  95.  
  96. Why on earth do you bring this up? It has nothing to do with C or the
  97. current discussion, or else I've missed something here.
  98.  
  99. /Lars
  100. --
  101. Lars Fischer, fischer@iesd.auc.dk | It takes an uncommon mind to think of
  102. CS Dept., Aalborg Univ., DENMARK. | these things.  -- Calvin
  103.