home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 17898 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  4.4 KB
  1. Xref: sparky comp.sys.amiga.programmer:17898 alt.folklore.computers:18401
  2. Path: sparky!uunet!rayssd!galaxia!animato!rlcarr
  3. From: rlcarr@animato.network23.com (Rich Carreiro)
  4. Newsgroups: comp.sys.amiga.programmer,alt.folklore.computers
  5. Followup-To: comp.sys.amiga.programmer
  6. Subject: Re: How should I learn C?
  7. Distribution: world
  8. Message-ID: <rlcarr.09er@animato.network23.com>
  9. X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith
  10. Date: 29 Dec 92 00:20:32 EST
  11. Organization: The Other Side of Life
  12. Lines: 94
  13.  
  14. In article <78849@hydra.gatech.EDU> gt6758b@prism.gatech.EDU (Michael Maverick Kopack) writes:
  15. > There are a lot of things about C that I find very frustrating after comming
  16. > from a decent course in Pascal. For one is the way that Arrays are handled.
  17. > I like being able to do stuff like    array [6..26] of int whereas in C you
  18. > get forced into calling the indeces 0-19. I also HATE that there are no true 
  19. > pass by reference parameters! 
  20.  
  21. [note: array [6..26] of int has 21 elements, and therefore would have indices
  22. 0-20 in C, not 0-19]
  23.  
  24. Yes there are -- you pass in a pointer.  This is NO different than what 
  25. Pascal does --- Pascal simply uses "syntactic sugar" to hide it from you, but
  26. passing a pointer is what it is actually doing in this case.  As for arrays
  27. that start at other than 0, once you understand pointers there's a relatively
  28. easy way, but use at your own risk:
  29. RANDOMTYPE foo_bad[21];
  30. RANDOMTYPE *foo;
  31. foo = &foo_bad[0] - 6;
  32.  
  33. You now can use foo[6] to foo[26] to access the arrays.  By extension you
  34. can even use negative subscripts (you can in theory -- I don't know off-hand
  35. if the language spec allows for it).
  36.  
  37. > 
  38. > It seems that C pretty much took Pascal and threw all the rules out the window!
  39.  
  40. Isn't C older than Pascal?  In any case, get a copy of Brian Kernighan's classic
  41. _Why Pascal Is Not My Favorite Programming Language_ (or some similar title).
  42. It's available somewhere; it was posted to alt.folklore.computers a month or
  43. so ago.  It's a wonderful point-by-point listing of the serious things that
  44. are wrong with Pascal.
  45.  
  46. > I can't imbed functions so other procedures can't see them (scoping rules),
  47.  
  48. True -- this can be annoying.  However, you can minimise namespace collisions
  49. somewhat by the judicious use of the "static" keyword.  Let's say that
  50. functions foo() and bar() are supposed to be visible to the world, and that
  51. auxfoo() and auxbar() are functions that foo() and bar() need buy shouldn't
  52. be world visible.  Create a sourcefile (say foobar.c) and define the functions
  53. as follows:
  54.  
  55. RANDOMTYPE foo(whatever)
  56. {
  57.  /* foo's code */
  58. }
  59. RANDOMTYPE bar(whatever)
  60. {
  61.  /* bar's code */
  62. }
  63. static RANDOMTYPE auxfoo(whatever)
  64. {
  65.  /* auxfoo's code */
  66. }
  67. static RANDOMTYPE auxbar(whatever)
  68. {
  69.  /* auxbar's code */
  70. }
  71.  
  72. Again, this is all within a single sourcefile, distinct from the other
  73. sourcefile which make up the rest of the program.  If you do this, only
  74. foo() and bar() will be visible to functions contained in other sourcefiles,
  75. while auxfoo() and auxbar() will be visible to foo(), bar(), and each other.
  76.  
  77. > I have to use global variables a lot (taught as a no-no at GT) and it just
  78.  
  79. There's nothing in C that should make you use globals where you did not use
  80. them in Pascal.  I don't understand this complaint.
  81.  
  82. > seems like C is TOO flexible! How do you guys get anything done when there are
  83. > about 500 different ways to do it?
  84.  
  85. There are ways that are generally objectively better (though of course the
  86. particulars of a program might override "accepted" ways).  Use them.  I know
  87. that's not much of an answer :-)  Check out some books on C,
  88. starting with the 2nd edition of Kernighan and Ritchie.  I've also liked
  89. _C Primer Plus_ by the Waite group.  I'm sure others will have recommendations.
  90. In any case, I'd rather have many ways to do something than have no way (which
  91. can happen in Pascal too often).
  92.  
  93. > Please, open my mind to C! I'd hate to have to try to do everything for my 
  94. > Amiga in Pascal, considering how much of the Amiga software is written in 
  95. > and documented for C......
  96.  
  97. Well -- this was my crack at it... :-)
  98.  
  99. > Michael Maverick Kopack                | Sex, drugs, rock and roll  
  100. > Internet: gt6758b@prism.gatech.edu     |and my Amiga, what else could
  101. >           kopack@vortex.erda.rl.af.mil |one ever want?     
  102. >           kopackm@lonex.rl.af.mil      \---------------------------------------
  103.  
  104. --
  105. Rich Carreiro                                  Home: (401)841-8514
  106. rlcarr@animato.network23.com
  107. uunet.uu.net!animato!rlcarr
  108.