home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / cplus / 19055 < prev    next >
Encoding:
Text File  |  1993-01-12  |  4.2 KB  |  96 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!spool.mu.edu!yale.edu!yale!gumby!destroyer!cs.ubc.ca!mprgate.mpr.ca!lichen!janzen
  3. From: janzen@lichen.mpr.ca (Martin Janzen)
  4. Subject: Re: C/C++ Correctness (was: Re: C/C++ Speed)
  5. Message-ID: <1993Jan13.022455.23208@mprgate.mpr.ca>
  6. Sender: janzen@lichen (Martin Janzen)
  7. Reply-To: janzen@mprgate.mpr.ca
  8. Organization: MPR Teltech Ltd.
  9. References: <1ipsk5INNf5m@aludra.usc.edu> <dak.726696239@tabaqui> <1993Jan11.163852.19740@informix.com> <1993Jan11.224238.22152@csservices.Princeton.EDU>
  10. Date: Wed, 13 Jan 93 02:24:55 GMT
  11. Lines: 83
  12.  
  13. In article <1993Jan11.224238.22152@csservices.Princeton.EDU>,
  14. blume@kastle.Princeton.EDU (Matthias Blume) writes:
  15. >The question should be: are programs written in C++ more reliable than those
  16. >written in C.  I serioulsy doubt that!
  17.  
  18. I beg to differ with this very general statement.  Obviously not every C++
  19. program is more reliable than every C program.  But my first "real" C++
  20. experience (on a recent UI project: ~50 classes, ~14K lines, ~3800 stmts)
  21. has been that reliability _can_ be improved by a number of C++ features,
  22. if you choose to take advantage of them.
  23.  
  24. The things that I've found contribute most to increased reliability are:
  25.  
  26. - the ability to encapsulate all of the code related to a particular
  27.   interface into one class.  This results in code which is easier to
  28.   read, and thus to review, test, debug, and maintain.
  29.  
  30. - the use of constructors and destructors.  These make it _much_ easier
  31.   to avoid memory allocation bugs, such as memory leaks and duplicate
  32.   calls to free().  (Though I'm not throwing out my "Purify" yet!)
  33.  
  34. - the ease with which Bertrand Meyer's notion of "programming by contract"
  35.   may be implemented.  Pre- and post-conditions may be checked by adding
  36.   assertions to the beginning and end of the appropriate methods.  (I
  37.   suppose that class invariants could be implemented as well; say, by
  38.   using a macro which is inserted before each exit from each method -- I
  39.   didn't go quite that far!)
  40.  
  41. Of course none of the above are exclusive to C++; you can accomplish the
  42. same things in many other languages.  But in my experience, C++ provided
  43. reasonably "natural" ways to do all of the above.
  44.  
  45.  
  46. >I'd rather stick to something simpler and more reliable than that.  If you
  47. >need inheritance et al. then use something that isn't suffering feature
  48. >cancer (for instance: Objective C)!
  49.  
  50. There are a number of languages that may be "better" in one way or
  51. another.  For instance, the new version of Eiffel sounds really good.
  52. But so far, I'd say that C++ still has an advantage based on other
  53. factors -- availability and tool support, to name just a couple.
  54.  
  55. >With a bit of discipline it is even
  56. >possible to write OO-programs in plain old C (Many people have done this as
  57. >an exercise, and literature about it will probably (hopefully) appear soon.)
  58.  
  59. Sure; you could even write OO programs in assembler, if you really want to.
  60. But try working with the X Toolkit or with OSF/Motif code for a while!  It's
  61. object-oriented C code all right, but it's pretty scary stuff...
  62.  
  63. Regarding some of Matthias' other criticisms:
  64.  
  65. >    C++
  66. >        - is highly complicated
  67.  
  68. No argument about that!
  69.  
  70. >        - has no fixed specification (or rather: the specification is
  71. >          a moving target)
  72. >        - employs a syntax that is even more ambiguous than that of C
  73. >        - has NO WORKING compiler that really implements the language
  74. >          (all compilers show major shortcomings in basic areas like
  75. >          constructor/destructor call placement)
  76.  
  77. Maybe I've just been lucky, but these haven't presented major problems.
  78.  
  79. >        - is overfeature[d] (who needs multiple inheritance?)
  80.  
  81. I do.  Not often; but it's useful for, say, mixin classes which
  82. implement the Model-View-Controller architecture...
  83.  
  84. >The sad truth is, however, that almost everybody seems to believe in C++
  85. >nowadays... :(  C++ will not be the solution to the current software crisis --
  86. >it will be the cause of the next one.
  87.  
  88. A bold statement! :-)   I guess we'll find out...
  89.  
  90.  
  91. -- 
  92. Martin Janzen                     janzen@mprgate.mpr.ca (134.87.131.13)
  93. MPR Teltech Ltd.                  Phone: (604) 293-5309
  94. 8999 Nelson Way                   Fax: (604) 293-6100
  95. Burnaby, BC, CANADA  V5A 4B5
  96.