home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / c / 12803 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  1.7 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!gatech!rpi!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Most difficult part of learning C?
  5. Date: 26 Aug 1992 15:58:13 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 27
  8. Message-ID: <17g9mlINNsu1@early-bird.think.com>
  9. References: <1992Aug25.180919.10370@samba.oit.unc.edu> <behrenss.714775792@hphalle6> <chuckb.714781695@milton>
  10. NNTP-Posting-Host: telecaster.think.com
  11.  
  12. In article <chuckb.714781695@milton> chuckb@milton.u.washington.edu (Chuck Bass) writes:
  13. >I would bet that assembly language programmers have no problem
  14. >picking up C's notion of pointers.
  15.  
  16. I disagree.  Assembly programmers are used to pointers being addresses, and
  17. arithmetic on pointers being address arithmetic.  They're probably the ones
  18. who get most confused by C's automatic scaling during ptr+integer
  19. calculations, and don't understand why p+=sizeof(*p) doesn't do what they
  20. expect.
  21.  
  22. On the other hand, perhaps your comment was motivated by the fact that most
  23. other high level languages don't provide pointer arithmetic at all.
  24. Programmers used to PL/O, Pascal, or Ada are familiar with pointers being
  25. used for things like linked lists, but not pointers into the middle of
  26. objects.  Assembly programmers can deal with pointers that can address
  27. anything.
  28.  
  29. I never had this problem because my introduction to pointers was in PL/I on
  30. Multics, which has extensions that perform pointer arithmetic (but since
  31. PL/I doesn't have typed pointers, the arithmetic is on the raw address,
  32. rather than being scaled automatically as in C).
  33.  
  34. -- 
  35. Barry Margolin
  36. System Manager, Thinking Machines Corp.
  37.  
  38. barmar@think.com          {uunet,harvard}!think!barmar
  39.