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

  1. Xref: sparky comp.lang.c++:11754 comp.std.c++:991
  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: Language extensions for run-time type identification
  6. Message-ID: <1992Jul29.192054.22533@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: <BryFLI.Hz2@world.std.com>
  11. Date: Wed, 29 Jul 92 19:20:54 GMT
  12. Lines: 87
  13.  
  14. In article <BryFLI.Hz2@world.std.com> wmm@world.std.com (William M Miller)  
  15. writes:
  16. > Consider this: dynamic typing is only required when you've "lost" the
  17. > exact type of the object to which an expression refers.  In all other
  18. > cases, the static type of the expression is sufficient, and the
  19. > compiler can just provide a direct reference to the typeinfo if the
  20. > program requests type information.
  21. >
  22. Definitely true.
  23.  
  24. > There are only two ways to "lose" the exact type in C++ (apart from
  25. > explicit casting to an unrelated type, for instance): conversion of a
  26. > pointer/reference to a derived class into a pointer/reference to a
  27. > base class, and conversion to void*.  
  28. >
  29. Also True, but only within a domestic environment.
  30.  
  31. > Doing something about the latter
  32. > is either very expensive or requires breaking compatibility with C
  33. > void* pointers (tagged pointers),
  34. >
  35. True, if you do not relate the void* to the tagged pointer. Only those  
  36. polymorphic pointers need to be tagged. void* is not a polymorphic pointer. If  
  37. we want an equivalent polymorphic pointer, we can introduce a new one:  
  38. anytype*, where anytype is supposed to be the root of class hierarchy. You get  
  39. penalty only when you use it.
  40.  
  41. > so realistically we are talking
  42. > about a requirement for RTTI that *only* has to deal with the results
  43. > of derived-to-base conversions.
  44. >
  45. Not exactly. It is true within a domestic environment.
  46.  
  47. > The question, then, is under what circumstances do such conversions
  48. > occur?  The premise of the current proposal is that you don't *do*
  49. > such conversions unless you have provided for polymorphic behavior,
  50. > i.e., virtual functions. Inheritance for factoring and sharing of
  51. > representation and code is fine, but in such applications you
  52. > typically don't rely on derived-to-base conversions.
  53. >
  54. Not entirely true even for a domestic system: 
  55.  
  56. I often have a class hierachy in which the base methods manipulate only on the  
  57. part of the base data and no virtualization is required. All the specific  
  58. operations in the derived classes will be performed from the specific  
  59. interfaces. But I still need a general interface that manipultes all of the  
  60. object at the base level. Virtual functions can help a lot in reducing the  
  61. neccessity of downcast and hence the need of RTTI. But virtual function does  
  62. not always help. Sometimes the specific interfaces and requirements can vary  
  63. greatly in derived classes, it is impossible to exract a common interface as a  
  64. virtual interface. In this case, I have to use RTTI rather than the virtual  
  65. function.
  66.  
  67. > The challenge, then, for those who view RTTI-via-vtable as
  68. > insufficient is to provide *concrete* counterexamples to this
  69. > assumption: applications where derived-to-base casting does occur
  70. > without the need for virtual functions and for which RTTI would
  71. > nevertheless be useful.  Are there such applications?
  72. Yes. 
  73.  
  74. I can maintain a group of passive objects without intrinsic behavioral  
  75. characteristics, needless to say any virtual functions. What I am concerned is  
  76. only the internal data structure. These objects are usually used to carry the  
  77. information and to be transfered between different environments. I need RTTI to  
  78. represent or transform these objects correctly. For example, to transform an  
  79. integer in an object from Intel 8086 form to network form. Although a simple  
  80. type id is usually insufficient for this case, but it provides a key to access  
  81. the detail type information in some type library generated by the compiler (I  
  82. just hate to see the game of waste: inventing one precompiler after another).
  83.  
  84. My multitasking system can also have an interface that take an object as input  
  85. from other task. Such object is not necessarily virtualized. Such type check is  
  86. usaually performed at run time. Without RTTI, my task may corrupt due to a  
  87. wrong input type. Without language supported RTTI, I have to provide my own  
  88. RTTI to solve this problem. If the system is general purposed and must be  
  89. integrated with the language environment, again, I have to write a precompiler  
  90. to create my own language (example: IDL for remote procedure call)!
  91.   
  92. And I'm sure many OO database and OS people can tell more.
  93.  
  94. Since OO technique is aimed mainly to developing large, complex and  
  95. coorperative systems, C++, as general purposed OO language, should at least  
  96. cover some main application areas.
  97.  
  98. David Shang
  99.