home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18266 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  1.4 KB
  1. Path: sparky!uunet!psinntp!gatekeeper.nsc.com!voder!genie!roger
  2. From: roger@genie.UUCP (Roger H. Scott)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: "type safety" deemed essential
  5. Message-ID: <448@genie.UUCP>
  6. Date: 20 Dec 92 17:49:42 GMT
  7. References: <1992Dec13.141400.5307@mole-end.matawan.nj.us> <1992Dec14.212143.15591@leland.Stanford.EDU> <rmartin.724430168@thor>
  8. Reply-To: roger@genie.UUCP (Roger H. Scott)
  9. Organization: proCASE Corporation, Santa Clara, CA
  10. Lines: 18
  11.  
  12. In article <rmartin.724430168@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  13. >kocks@leland.Stanford.EDU (Peter Kocks) writes:
  14. >
  15. >>My $0.02.  Use Obj-C.  I have just spent a fair amount of time
  16. >>comparing strong vs weak type casting systems [...]
  17. >
  18. >For any significant industrial application, I think strong typing is
  19. >utterly essential.  It is just too easy to create horrible run time
  20. >errors without type safety.  
  21.  
  22. This sounds like theory rather than practice speaking.  Let's hear from the
  23. (net) C++ user community: who has written a non-trivial commercial C++ 
  24. application *without* making significant use of either type casting [(T *)]
  25. or run-time type checking [Bar *bar_p = foo_p->asBar();]?  I maintain that
  26. C++ makes it *very* difficult to do without at least one or the other of these
  27. (Eiffel-style "anchored" virtual function return types would go a long way to
  28. alleviate this).  I'm hoping that templates will help in this regard, but they
  29. haven't been available long enough to judge.
  30.