home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / cplus / 19013 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  2.9 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!olivea!mintaka.lcs.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: feedback wanted on appropriate OOPL
  5. Message-ID: <TMB.93Jan12172611@arolla.idiap.ch>
  6. Date: 13 Jan 93 01:26:11 GMT
  7. References: <726278910snx@trmphrst.demon.co.uk> <rmartin.726674455@thor>
  8.     <TMB.93Jan10170408@arolla.idiap.ch> <1993Jan10.220917.22879@netcom.com>
  9.     <TMB.93Jan11010738@arolla.idiap.ch> <rmartin.726795534@thor>
  10. Reply-To: tmb@idiap.ch
  11. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  12.     Perceptive)
  13. Lines: 52
  14. NNTP-Posting-Host: arolla.idiap.ch
  15. In-reply-to: rmartin@thor.Rational.COM's message of Mon, 11 Jan 1993 23:38:54 GMT
  16.  
  17. In article <rmartin.726795534@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  18.  
  19.    tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  20.  
  21.    |Detecting errors at compile time is better than detecting them
  22.    |at runtime. But detecting errors at runtime is better than not
  23.    |detecting them at all.
  24.  
  25.    |Unfortunately, the majority of errors that are detectable at all can
  26.    |only be detected at runtime.
  27.  
  28.    I disagree with this statement.  In my experience, the majority of
  29.    detectable errors, are detected in the compilation phase (and in the
  30.    code review phase of course).
  31.  
  32. Array bounds violation, bad pointers, and type errors involving type
  33. unions, are all detectable errors, but for most algorithms and
  34. programs, they are not detectable at compile time.
  35.  
  36. From a practical point of view, I have used languages that have much
  37. stricter compile time error checking than C++, and they still need a
  38. lot of runtime checks.
  39.  
  40.    | C++ has no support for runtime error
  41.    |checking, 
  42.  
  43.    Although there are common environments that provide it.
  44.  
  45. These "common environments" have a significant overhead, making them
  46. useless for production use (if you are willing to accept that kind of
  47. overhead, you would be better served with another language).
  48. Furthermore, even for debugging some kinds of applications, they are
  49. too slow to get your code to the point where the bug occurs.
  50.  
  51.    This I doubt.  I think it is more that some runtime features are
  52.    expensive, period.  Languages that support them, have made a different
  53.    tradeoff than that made in C++, and have sacrificed something else
  54.    (probably speed) thereby.
  55.  
  56. Well, we'll just have to see. All the attempts of supporting safety in
  57. C++ that I have seen (Purify, ObjectCenter, user-defined classes,
  58. various GC implementations) have had much more overhead for supporting
  59. those features than other languages.
  60.  
  61. In any case, it's not an "either/or" situation. You can support safety
  62. features like array bounds checking etc. and let the user
  63. enable/disable it for specific sections of code. The only reason why
  64. this isn't a realistic approach in C++ is for reasons of backwards
  65. compatibility with C, not because the C++ approach is somehow "more
  66. efficient".
  67.  
  68.                     Thomas.
  69.