home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11842 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  4.0 KB
  1. Xref: sparky comp.lang.c++:11842 comp.std.c++:1004
  2. Path: sparky!uunet!dtix!darwin.sura.net!convex!constellation!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Newsgroups: comp.lang.c++,comp.std.c++
  5. Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
  6. Message-ID: <1992Jul30.172830.18501@ucc.su.OZ.AU>
  7. Date: 30 Jul 92 17:28:30 GMT
  8. References: <1992Jul28.210755.3548@ucc.su.OZ.AU> <1992Jul29.162440.21848@cadsun.corp.mot.com>
  9. Sender: news@ucc.su.OZ.AU
  10. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  11. Lines: 101
  12. Nntp-Posting-Host: extro.ucc.su.oz.au
  13.  
  14. In article <1992Jul29.162440.21848@cadsun.corp.mot.com> shang@corp.mot.com writes:
  15. >In article <1992Jul28.210755.3548@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John  
  16. >MAX Skaller) writes:
  17. >> >
  18. >> >> NOW: I want to demonstrate why using RTTI is WRONG in this case,
  19. >> >> and why the Species() function is required.    
  20. >> >>
  21. >> >Remenber, your function Species() IS JUST FOR THE PURPOSE TO PROVIDE RTTI. 
  22. >> 
  23. >>     Yes. I'm not against having run-time-type information
  24. >> available. 
  25. >
  26. >See your original statement -- what you want to demonstrate.
  27.  
  28.     I refered to compiler generated RTTI. User generated RTTI
  29. must obey the current restrictions of C++, and so is as sound and safe
  30. as C++ currently is. I also refered to a specific case in one place,
  31. and say in general in another, intending to say 'always'. OK?
  32.  
  33. >
  34. >> >> 
  35. >> >> The demonstration is so simple, and applies so generally, I wonder
  36. >> >> why I didnt think of it before.
  37. >> >> 
  38. >> >>     class DOG : Animal { ....
  39. >> >>     class HUND : Animal { .. // german programmer
  40. >> >> 
  41. >> >This is never an execuse. If it is, your Species() function has the same  
  42. >> >problem:
  43. >> >
  44. >> >     char* DOG::Species()
  45. >> >        { return "DOG"; }
  46. >> >     char* DOG::Species()
  47. >> >        { return "HOUND"; }   // german programmer
  48. >> 
  49. >>     What?? The compiler catches this error: it is a duplicate
  50. >> definition.
  51. >>
  52. >The class DOG can be declared as static in different modules and it is highly  
  53. >possible if an Australian and a German work for the same project that is  
  54. >separated into many different modules.
  55.  
  56.     Sorry. The linker catches the error, not the compiler.
  57.  
  58. > 
  59. >> Actually, I think downcasting is OK when you already knew what the
  60. >> type was, or could have. Then it is just a convenience. And safe.
  61. >> 
  62. >Then we have not disagreement any more.
  63.  
  64.     Well, I'm not sure about that. We certainly dont have a
  65. specific *agreement* about when downcasting is sound and when
  66. it is not, nor how to suitably constrain it.
  67.  
  68.     My efforts at the moment are directed to preserving the
  69. mechanism suggested for Bjarne's proposal, that is, using
  70. a downcasting of pointers, getting 0 if the wrong type
  71. is there (and exceptions to references).
  72.  
  73.     I am looking at a constraint where all the things that
  74. a function can downcast to must be listed (or implied by the list)
  75. in the interface.
  76.  
  77.     f(Base[Derived1,Derived2]*);
  78.  
  79.     This mechanism has some nice features, although I am
  80. not sure about its soundness yet.
  81.  
  82.     Member functions can always downcast to their class.
  83. That immediately implies a 'thisclass' facility, and with no
  84. additional syntax in the declaration. 
  85.  
  86.     Furthermore, explicit downcasting operators are not 
  87. required always, since the declaration already lists the legal
  88. downcasts.
  89.  
  90.     Even better, the syntax might support casting to unrelated
  91. types, and can be implemented then, and when no virtual functions
  92. are available, by using tagged pointers or some other mechanism.
  93.  
  94.     Finally, for the moment, one can implement
  95.  
  96.     f(Base[Derived1, Derived2]* b)
  97.     {
  98.         ...
  99.         type switch(ab) {
  100.         case Derived1:
  101.             b->Derived1_member();
  102.         case Derived2:
  103.             b->Derived2_member();
  104.         default:
  105.             b->Base_member();
  106.         };
  107.     }
  108.  
  109. although there would have to be an implied break after each case.
  110. -- 
  111. ;----------------------------------------------------------------------
  112.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  113.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  114. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  115.