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

  1. Xref: sparky comp.lang.c++:11259 comp.std.c++:902
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!caen!hellgate.utah.edu!asylum.cs.utah.edu!clark
  4. From: clark%asylum.cs.utah.edu@cs.utah.edu (Charles Clark)
  5. Subject: Re: Language extensions for run-time type identification
  6. Date: 21 Jul 92 13:55:37 MDT
  7. Message-ID: <1992Jul21.135537.23421@hellgate.utah.edu>
  8. Followup-To: comp.lang.c++,comp.std.c++
  9. Sender: clark@cs.utah.edu
  10. Organization: University of Utah CS Dept
  11. References: <14ft2uINNjh4@agate.berkeley.edu> <1992Jul21.143131.6902@cadsun.corp.mot.com>
  12. Lines: 42
  13.  
  14. In article <1992Jul21.143131.6902@cadsun.corp.mot.com> shang@corp.mot.com writes:
  15. >In article <14ft2uINNjh4@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe  
  16. >Buck) writes:
  17. >> * the fact that it is trivial to force any class for which run-time type
  18. >>   identification is needed to have a virtual function table (simply add
  19. >>   a virtual destructor).
  20. >>
  21. >Adding something virtual just for the purpose that has nothing to do with it?
  22.  
  23. I agree, forcing the programmer to add a virtual destructor (or any virtual 
  24. function) to the design of his/her classes (so the resulting vtable can
  25. be used for type id) is dubious.  Unfortunately, a programmer without access
  26. to a a C++ compiler which provides run-time type id can do no better.
  27.  
  28. >> In most implementations of classes with virtual functions, each object
  29. >> already has, in effect, a type-ID: the pointer to the virtual function
  30. >> table.  This is a natural hook on which to hang run time type checking.
  31. >>
  32. >The pointer to vtable can not work as a type-ID for a language with multiple  
  33. >inheritance. An object of particular class derived from multiple bases may  
  34. >contain serveral different vtable references. Different base pointers to the  
  35. >same object may use different vtable pointers.
  36.  
  37. Indeed.  The above scheme fails when vtables are shared between base and 
  38. derived classes.  This sharing occurs when using multiple inheritance 
  39. (or virtual base classes) and no inherited methods from one of the base 
  40. classes are redefined.  A cast to that base, and reference to the vtable, will
  41. yield the (shared) base vtable.  Ooops, wrong type id...
  42.  
  43. Note that this is a compiler implementation detail -- an optimization that
  44. C++ compilers use to reduce the number of vtables generated.  One could
  45. modify the compiler to not make this optimization and generate fresh vtables
  46. for the base portions of derived classes.  Now, if you've got your heart set
  47. on run-time type id and you're prepared to modify the compiler, there is
  48. no point in forcing the programmer to write useless virtual functions so
  49. that a vtable will be generated.  The compiler can be modified to always
  50. generate a vtable (although it may sometimes be empty).
  51.  
  52. The overhead of doing this is one word per instance of a class that would
  53. not normally have a vtable (plus the extra vtables).
  54.  
  55.     --Charles (clark@cs.utah.edu)
  56.