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

  1. Xref: sparky comp.lang.c++:11333 comp.std.c++:915
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!usc!sdd.hp.com!mips!mips!rtech!ingres!bobm
  4. From: bobm@Ingres.COM (Bob McQueer)
  5. Subject: Re: Language extensions for run-time type identification
  6. Message-ID: <1992Jul22.173019.6534@pony.Ingres.COM>
  7. References: <14ft2uINNjh4@agate.berkeley.edu>
  8. Date: 22 Jul 92 17:30:19 GMT
  9. Lines: 35
  10.  
  11. In <14ft2uINNjh4@agate.berkeley.edu>,
  12.     dated 21 Jul 92 02:34:06 GMT,
  13.     jbuck@forney.berkeley.edu (Joe Buck) writes:
  14.  
  15. > In most implementations of classes with virtual functions, each object
  16. > already has, in effect, a type-ID: the pointer to the virtual function
  17. > table.  This is a natural hook on which to hang run time type checking.
  18.  
  19. I think Mr. Buck has hit the nail on the head here.  I've been meaning to ask
  20. about this myself, and was happy to see this discussion thread start.  The
  21. virtual function table exists as a 1-per-class structure, and is the natural
  22. place to insert other runtime class information without replicating anything.
  23. The reasonable overhead on each object instantiation would be 1 pointer to
  24. the virtual function table, which we might want to start calling a class
  25. descriptor, or something like that.
  26.  
  27. I think we have to recognize that C++ is not a purist's OO language - it
  28. is a way of adding OO functionality to an existing language.  Its strength
  29. lies in being able to use an OO paradigm, while still retaining the
  30. efficiency of C, and having "escape hatches".  Insisting that only certain
  31. classes can have runtime descriptors seems reasonable, given this intent.
  32.  
  33. What I was going to ask about was actually support for an "isa" operation,
  34. which requires some type of runtime definition.  Yes, this type of thing can
  35. be abused, but it is definitely useful.  It should NOT be used as a substitute
  36. for proper subclassing and definition of virtual functions, but I think it
  37. is needed.
  38.  
  39. Another aspect - if we have the ability to get at class descriptors, can there
  40. be an extension which allows them to be used with the "new" operator to
  41. parameterize the class of object being allocated.  I think that as "service"
  42. classes begin to be provided, it might be handy.  Think in terms of C++
  43. application generators which generate the code to manipulate certain classes of
  44. objects, which may be customized by allowing the user to subclass the basic
  45. types.
  46.