home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / alt / msdos / programm / 3033 < prev    next >
Encoding:
Internet Message Format  |  1992-12-28  |  2.6 KB
  1. Xref: sparky alt.msdos.programmer:3033 comp.os.msdos.programmer:11664 comp.sys.ibm.pc.programmer:692 comp.lang.c++:18472 comp.lang.c:18944
  2. Path: sparky!uunet!dtix!darwin.sura.net!spool.mu.edu!think.com!ames!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!news!nntpd.lkg.dec.com!speedy.zko.dec.com!feldman
  3. From: feldman@speedy.zko.dec.com (Gary Feldman)
  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: <1992Dec28.184038.20725@nntpd.lkg.dec.com>
  7. Date: 28 Dec 92 18:40:38 GMT
  8. References: <1992Dec24.154204.25248@blkbox> <1992Dec24.230420.4243@sequent.com> <1992Dec25.050515.20871@ncsu.edu> <1992Dec25.073517.16089@grebyn.com>
  9. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  10. Reply-To: feldman@speedy.zko.dec.com (Gary Feldman)
  11. Organization: Digital Equipment Corporation
  12. Lines: 39
  13.  
  14.  
  15. In article <1992Dec25.073517.16089@grebyn.com>, malak@grebyn.com (Michael Malak) writes:
  16.  
  17. |>It's blase attitudes such as that that are responsible for so many
  18. |>bug-ridden programs.  Besides allowing one to understand what is
  19. |>really going on, assembly is necessary for tracking down compiler
  20. |>bugs.  In my opinion, you cannot be a real C programmer without knowing
  21. |>assembly.
  22. |>
  23. |>There is just _so_ much involved with learning C fully.  Shortcuts lead
  24. |>to mediocre proficiency, which leads to disaster in a language as
  25. |>unforgiving and flexible as C.
  26. |>
  27. |>
  28.  
  29. That's an interesting perspective, with a good deal of validity, but there
  30. is another side to this.
  31.  
  32. First, while compilers do have bugs, decent ones don't have all that many,
  33. and they're not all in the code generator.  And while I've found my share of 
  34. code generator bugs, they don't really happen often enough to make that a 
  35. requirement for learning assembly language.  
  36.  
  37. More importantly, allowing the assembly language view to influence your
  38. coding is more likely to be a source of bug-ridden programs, and not
  39. a preventative.  This is especially true these days when more and more
  40. programs are being written to run on multiple architectures.  In such cases,
  41. assumptions made at the assembly level on one machine can be horribly invalid
  42. on another.  All sorts of things -- pointer arithmetic, alignment assumptions,
  43. speed assumptions, big endian vs. little endian, regiter behavior, casting
  44. behavior -- can break.
  45.  
  46. If your goal is bug-free programs, then except for some limited problem domains,
  47. it is far more important to really understand the abstract semantics of C 
  48. independently of any assembly language, as well as quality design and testing
  49. methodologies.  
  50.  
  51.    Gary
  52.    #include <standard_disclaimer.here>
  53.