home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / c / 19572 < prev    next >
Encoding:
Text File  |  1993-01-12  |  1.5 KB  |  35 lines
  1. Newsgroups: comp.lang.c
  2. From: raph@panache.demon.co.uk (Raphael mankin)
  3. Path: sparky!uunet!pipex!demon!panache.demon.co.uk!raph
  4. Subject: Re: Moving from Pascal to C, Help please!!!!!! 
  5. Distribution: world
  6. References: <1993Jan10.003223.21578@leland.Stanford.EDU>
  7. Organization: Solvfield Ltd.
  8. Reply-To: raph@panache.demon.co.uk
  9. X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19)
  10. Lines: 20
  11. Date: Sun, 10 Jan 1993 21:59:27 +0000
  12. Message-ID: <726703167snz@panache.demon.co.uk>
  13. Sender: usenet@demon.co.uk
  14.  
  15. Just for the record. I've been programming now for 30 years, writing
  16. compilers operating systems, network management, modem firmware, and name
  17. and address label printing programs. Over that time I've learnt the virtues
  18. of virtue.
  19.  
  20. On the topic of pointers; if you regard a pointer purely as an object reference
  21. and not as a machine address ('object' here has nothing to do with OOP) then you
  22. will not go far wrong. My experience is that a vast proportion of programming
  23. errors (not design errors) are pointer faults of some sort -- and I'm not
  24. referring just to my own code. I would class pointer modification as a kind
  25. of dynamic unstructuredness, just as uncontrolled GOTOs are a static 
  26. unstructuredness.
  27.  
  28. The remarks in K&R about using pointer modification to obtain a 'more 
  29. efficient' subscripting predate the advent of optimising C compilers. You can
  30. now get compilers that will do strength reduction on you subscripts, so let
  31. the compiler do the hard work so keep your code clear and simple for the
  32. human reader.
  33. --------------
  34. Raphael Mankin            Nil taurus excretum
  35.