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

  1. Xref: sparky comp.lang.c++:11476 comp.std.c++:939
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!gatech!destroyer!gumby!wupost!sdd.hp.com!decwrl!mips!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  4. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  5. Subject: Re: Language extensions for run-time type identification
  6. Message-ID: <1992Jul24.142452.756@ucc.su.OZ.AU>
  7. Sender: news@ucc.su.OZ.AU
  8. Nntp-Posting-Host: extro.ucc.su.oz.au
  9. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  10. References: <1992Jul21.094204.20100@mole-end> <1992Jul22.150330.6160@cadsun.corp.mot.com> <1992Jul23.183041.147@uunet.uu.net!mole-end>
  11. Date: Fri, 24 Jul 1992 14:24:52 GMT
  12. Lines: 45
  13.  
  14. In article <1992Jul23.183041.147@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
  15. >In article <1992Jul22.150330.6160@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
  16. >> In article <1992Jul21.094204.20100@mole-end> mat@mole-end writes:
  17. >> > 
  18. >> > The assumption underlying the decision to include only classes with
  19. >> > virtual functions is that a class that has no polymorphic behavior
  20. >> > whatsoever (not even a virtual destructor) cannot be used in any way
  21. >> > that is both safe and interesting even with the proposed runtime type
  22. >> > support.  Can you refute this assumption?
  23. >> > -- 
  24. >
  25. >> First of all and to be specific to C++, it is the class hierarchy, or  
  26. >> inheritance and the polymorphic pointers that lead to the necessity of
  27. >> run time type checking. It is not the virtual behaviors of a class.
  28. >> We still need run time type check even if we disallow any virtual behaviors
  29. >> in C++. Therefore, the assumption is laid on the wrong ground.
  30. >
  31. >But without virtualization (polymorphic behavior) derivation is effectively
  32. >useless.  There is no reason to code inheritance without providing for
  33. >virtualization.  Then the case which you mention is of no use unless and
  34. >until it is provided with RTTI; providing RTTI for it using reasonable
  35. >and economical mechanisms would violate certain assumptions that C++ allows
  36. >its users to make (C struct compatability).
  37.  
  38.     But I would make that argument backwards.
  39.  
  40.     One often wants het. aggregates of unrelated types.
  41.     Actually, these are aggregates of the *same* type,
  42. namely, the union of the unrelated types.
  43.  
  44.     On the otherhand, polymorphism is the mechanism by which
  45. the derived type NEED NOT BE KNOWN. Indeed, if we are to preserve
  46. the open/closed principle, MUST NOT BE KNOWN.
  47.  
  48.     So you (well, X3) is considering using RTTI in
  49. precisely the case it is not needed, and not supplying it
  50. when it actually could be useful :-)
  51.  
  52.  
  53. -- 
  54. ;----------------------------------------------------------------------
  55.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  56.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  57. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  58.