home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11297 < prev    next >
Encoding:
Text File  |  1992-07-21  |  8.6 KB  |  188 lines

  1. Xref: sparky comp.lang.c++:11297 comp.std.c++:906
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!ftpbox!motsrd!news
  4. From: shang@corp.mot.com (David (Lujun) Shang)
  5. Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
  6. Message-ID: <1992Jul22.022218.1115@cadsun.corp.mot.com>
  7. Sender: news@cadsun.corp.mot.com
  8. Reply-To: shang@corp.mot.com
  9. Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
  10. References: <1992Jul21.162659.25474@ucc.su.OZ.AU>
  11. Date: Wed, 22 Jul 92 02:22:18 GMT
  12. Lines: 174
  13.  
  14. In article <1992Jul21.162659.25474@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU  
  15. (John MAX Skaller) writes:
  16. >     In general C++ programming I do not agree that it is
  17. > necessary to recover arbitrary type information. That is because,
  18. > quite simply, you CANNOT use it.
  19. >
  20. "In general C programming I do not agree that it is necessary to use  
  21. inheritance of structure. That is because, quite simply, you CANNOT use it"
  22. -- I don't like the argument. We are not talking about C++ programming. We are  
  23. talking about the enhancement of the C++. If this argument could make any  
  24. sense, why should we need C++?
  25.  
  26. In article <1992Jul20.215058.1216@cadsun.corp.mot.com> I write:
  27. > >What I disagree is  
  28. > >the argument that the design of heterogeneous collection is fundamentally  
  29. > >wrong, which, of cause, is not your statement.
  30. >
  31.  
  32. In article <1992Jul21.162659.25474@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU  
  33. (John MAX Skaller) replies:
  34. >     I think I should clarify here: I am arguing against
  35. > DOWNCASTING. 
  36. I am against *unsafe* downcasting too. What we are arguring about is not the  
  37. downcasting. It is the run time type checking: whether it is necessary.
  38.  
  39. >     I am not against collections of objects all derived
  40. > from a common base provided you access them via the base.
  41. > That is the vey point of inheritance, after all.
  42. > In this case the objects are all of the same type:
  43. > it is homogeneous at the level it is accessed and
  44. > heterogeneous at the actual object level, but the actual
  45. > object level is not accessible.
  46. >
  47. True. I'm always in favor of doing that. We can always add member funtions and  
  48. virtual member functions to aviod downcasting an element in a *domestic*  
  49. heterogeneous collection or structure. But this does not mean that the run time  
  50. type info is not necessary. In case of a foreign heterogeneous collection, we  
  51. often need the run time type info, need to store and export the type info  
  52. together with the object. 
  53.  
  54. >     I am not against collections of objects of completely
  55. > unrelated types provided the types are drawn from a finite
  56. > and statically known set. In this case there is a 'type' which
  57. > is the finite union of those types, so again, the collection
  58. > is really homogeneous wrt that type.
  59. >
  60. This case exactly examplifies the necessity of runtime type info. Given an  
  61. element in this collection, you need run time type info to identify its type.  
  62. Otherwise, how do you do with the element which may be in one of the types that  
  63. are *completely unrelated*, say { int, float, doulbe }?
  64.  
  65. >     I am against using, in general programming,
  66. > DOWNCASTING or run-time type information to defeat the type system.
  67. >
  68. I just don't understand! Run time type check is a facillity to prevent careless  
  69. downcast to defeat the type system. How can you say that it is used in general  
  70. programming to defeat the type system?
  71.  
  72. >     I agree that in Debuggers and other such programs
  73. > these facilities are essential, indeed, you need much more
  74. > than a mere safe downcast or run-time type code. In a debugger,
  75. > for example, you need in effect run-time access
  76. > to the complete declaration and definintion of each class in
  77. > the whole program!
  78. >
  79. A simple type id can be a key for a debugger to access to the complete  
  80. declaration and definintion of each class in the whole program. We are not  
  81. necessary to include the complete type information at run time.
  82.  
  83. >     C++ does NOT have facilities at present to do this.
  84. > I am NOT against adding them. But I would be against using these
  85. > facilities in the general programming context for which C++
  86. > was intended and where such mechanism are *dangerous*.
  87. >
  88. Again, I can't understand. Run time type check is not a dangerous mechanism. On  
  89. the contrary, it is used prevent potential dangers.
  90.   
  91. >     Clearly, for example, a debugger which allows you
  92. > to modify instances of a class breaks encapsulation!
  93. > It breaks almost every principle you can think of. 
  94. > It is meant to: you use the debugger when a more important
  95. > thing is already broken : your program :-)
  96. Here, you goes too far. A debugger can break every principle of encapsulation  
  97. and protection only through low level programming facillities (e.g. the bitwise  
  98. and bytewise read/write, enforced typecasting between different types, machine  
  99. addresses, etc.). But a debugger can never break any principle of encapsulation  
  100. and protection only through run time type check. Remember: run time type  
  101. checking does not allow to cast objects which are actually of different types.
  102.  
  103. Even we stick to homogeneous programming, we still need run time type checking.  
  104. One of your reason against the concept of "thisclass" is that it needs run time  
  105. type checking, which you view as a disadvantadge. "thisclass" is just a  
  106. facillity to describle homogeneous data structure.
  107.  
  108. Okay, let's get rid of the concept of "thisclass" for the time being. Now, is  
  109. it true that run time type checking is no longer needed for homogeneous data  
  110. structure? No. Without covariant type specification (now, we come to our  
  111. original subject) in derived classes, we still have to run time type check the  
  112. type of arguments in derived classes in order to prevent any violation. Let's  
  113. consider a homogeneous animal collection:
  114.  
  115.     class Animal;
  116.     class AnimalGroup
  117.     { protected:
  118.        Animal * animals;
  119.       public:
  120.        virtual void accept (Animal *ap) {...};
  121.         ...
  122.     };
  123.  
  124. Since it is a homogeneous collection, it should contains animals of the same  
  125. type. The concept of "same type" is relatively dependend on what the class  
  126. designer means. Suppose the same type" is based on the *family* according to  
  127. the systemtic zoology. Then the collection should be of all dogs, or all cats,  
  128. etc. We have to run time type check the input of "accept" in order to ensure a  
  129. proper call:
  130.  
  131.     class Cat: public Animal;
  132.     class CatGroup: public AnimalGroup
  133.     { protected:
  134.          // Animal * animals;
  135.          // I wish I could narrowing the scope of "animals" to Cat here
  136.          // but unfortuanetly I can't do that in C++. Well, I'll keep the
  137.          // fact in my mind and assume that it has been narrowed.
  138.        public:
  139.          void accept (Animal *ap)
  140.             // I wish I could narrow the scope of "ap" to Cat here,
  141.             // but unfortunately, if I do, it will not the function that
  142.             // will override the virtual function defined in the base, and 
  143.             // then if someone operates on this cat group through a AnimalGroup
  144.             // interface, it could be totally wrong! 
  145.          {  // Okay, since we cannot present a type safe interfacewe in C++, 
  146.             // we have to run time type check here whether *ap is the right
  147.             // animal we should accept.
  148.             if (typeof(*ap)==Cat) 
  149.                // put this cat into the group according to the specific
  150.                // orgnization of the cat family
  151.             else 
  152.                // we can do nothing here
  153.          };
  154.       };
  155.  
  156. [people may suggest using templates for this case. But I happened to be a  
  157. person dislikes the C++-style templates, on which I have already posted my  
  158. opinions in this news group. Specifically for this topic, using templates, you  
  159. cannot achieve a polymorphic interface on AnimalGroup. For example, if I want  
  160. to define a heterogeneous collection of the animal groups, how can I implement  
  161. a general interface to access to concrete animal groups in this heter  
  162. collection? Using temaplate again?  No. It doesn't help, since templates does  
  163. not support heterogeneous data structure.].
  164.  
  165. What I give is only a very simple example. In practice, specialization in  
  166. derived classes is a very commom requirement. Without run time type check,  
  167. calling functions in derived classes through a base interface could be very  
  168. dangerous.
  169.  
  170. Even we have run time type check, it is still not safe to code the functions in  
  171. derived classes if I happened to forget the run-time type checking. We can pick  
  172. up the topic of covariant specification now. only if we can specialize the  
  173. interface in derived classes, can both calling abd coding functions in derived  
  174. classes be free of any violation.
  175.  
  176. The concept of "thsclass" is one step close to this goal.
  177.  
  178. David Shang
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.