home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11251 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  1.5 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!swrinde!mips!pacbell.com!att!att!allegra!alice!bs
  2. From: bs@alice.att.com (Bjarne Stroustrup)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Language extensions for run-time type identification
  5. Message-ID: <23263@alice.att.com>
  6. Date: 21 Jul 92 17:25:52 GMT
  7. References: <EY048MK@netmbx.netmbx.de> <TMB.92Jul20182052@arolla.idiap.ch>
  8. Organization: AT&T Bell Laboratories, Murray Hill NJ
  9. Lines: 21
  10.  
  11.  
  12.  
  13.  
  14. tmb@arolla.idiap.ch (Thomas M. Breuel @ IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  15. Perceptive)) writes
  16.  
  17.  > As I understand it (I haven't read the proposal), there will
  18.  > apparently be a half-hearted attempt at adding runtime type tags to
  19.  > some user-defined classes. From the descriptions of the proposal that
  20.  > I have heard, that will not be sufficient to make the C++ language
  21.  > safe (in the sense of eliminating most sources of "undefined
  22.  > behavior"). In fact, at best, it will encourage a careless programming
  23.  > style that relies on runtime type tests rather than inheritance and
  24.  > virtual functions.
  25.  
  26. I have no doubts that whatever mechanism for run-time type identification
  27. added to C++ (if any) will fail to please everybody. In fact, that is unavoidable
  28. since the the desires of various people in this area are quite contradictory.
  29. However, it might be an idea for people to refrain from condemning a proposal
  30. until they have seen it. Also, the mechanism will probably change based on
  31. discussion and constructive critism.
  32.