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

  1. Xref: sparky comp.lang.c++:11232 comp.std.c++:895
  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: <1992Jul21.143131.6902@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: <14ft2uINNjh4@agate.berkeley.edu>
  11. Date: Tue, 21 Jul 92 14:31:31 GMT
  12. Lines: 48
  13.  
  14. In article <14ft2uINNjh4@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe  
  15. Buck) writes:
  16. > * the virtual impossibility of designing a more general solution that does
  17. >   not break compatibility with C structs (a requirement that may be
  18. >   meaningless to theoretical folks but that is nevertheless vital).
  19. >   This constraint forbids adding any data to the object of any kind.
  20. >
  21. The object code does not necessarily include any code about the type  
  22. information. Encoding vtable references into object code is a particular way  
  23. applied by the current C++ implementation. For a complete solution to run time  
  24. type check, this technique must be changed. I've mentioned several times, the  
  25. "tagged pointer" technique is the proper way to achieve this goal. Only those  
  26. polymorphic pointers need to be tagged (not all pointers). The tagged pointer  
  27. is not an overhead since it already eliminates the necessity to tag an object. 
  28.  
  29. > * the fact that it is trivial to force any class for which run-time type
  30. >   identification is needed to have a virtual function table (simply add
  31. >   a virtual destructor).
  32. >
  33. Adding something virtual just for the purpose that has nothing to do with it?
  34.  
  35. > In most implementations of classes with virtual functions, each object
  36. > already has, in effect, a type-ID: the pointer to the virtual function
  37. > table.  This is a natural hook on which to hang run time type checking.
  38. >
  39. The pointer to vtable can not work as a type-ID for a language with multiple  
  40. inheritance. An object of particular class derived from multiple bases may  
  41. contain serveral different vtable references. Different base pointers to the  
  42. same object may use different vtable pointers.
  43.  
  44. > I could also argue the other way: for a debugger, it isn't enough to
  45. > identify all class objects.  I also need to be able to identify the
  46. > types of any int, double, pointer, or reference variables.  There's no
  47. > inherent reason why being able to identify all classes, but no other
  48. > variable types, is a more natural or useful division that just being
  49. > able to identify objects that have virtual functions.
  50. I fully agree with you when you argue the other way. In fact, it is possible  
  51. and practicable to identify any types and classes, no panelty on object codes,  
  52. especially for those objects of conventional C types. The only panelty is an  
  53. additinal integer (used as internal type identifier) for each type or class.  
  54. But we can benefit a lot: integrating conventional C types into class hierarchy  
  55. without additional overhead, explicit run time type check to prevent all the  
  56. type error at compile time, type-safe cast, to solve problem with "sizeof"  
  57. operator, problem with pointer increasement and decreasement, problems with  
  58. covariant type in derived classes, and many many other interesting things. 
  59.  
  60. David Shang
  61.