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

  1. Xref: sparky comp.lang.c++:11616 comp.std.c++:964
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!darwin.sura.net!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: <1992Jul27.180115.1889@pony.Ingres.COM>
  7. References: <1992Jul24.070325.1597@uunet.uu.net!mole-end>
  8. Date: 27 Jul 92 18:01:15 GMT
  9. Lines: 31
  10.  
  11. In <1992Jul24.070325.1597@uunet.uu.net!mole-end>,
  12.     dated Fri, 24 Jul 1992 07:03:25 GMT,
  13.     mat@uunet.uu.net!mole-end writes:
  14.  
  15. > And not to make you too happy: comparing vtable pointers could only be
  16. > a first step unless you are absolutely sure that the compilation and
  17. > linking system will never duplicate a vtable.  This is a hard assumption
  18. > to prove, especially with dynamic linking of new types.
  19.  
  20. I think it is just a first step anyway - when I want to know at run time if
  21. an object is of a particular class, what I really want to ask is "is it this
  22. class, or any class derived from it?", which implies somebody taking the
  23. vtable (enhanced into class descriptor) pointer in the object instantiation,
  24. and ascending through its parents.  With multiple inheritance, there can be
  25. several flavors of this question.
  26.  
  27. As has already been said, this sort of thing can be abused, and is not a
  28. substitute for proper use of virtual methods, but it IS useful.
  29.  
  30. I would also like to see the ability to parameterize the type handed
  31. to the "new" operator - logically, this thing is a class descriptor also.
  32.  
  33. Perhaps the committee ought to be considering the various sorts of "meta"
  34. operations people want to perform which involve parameterization of or
  35. manipulation of type information, and see if we shouldn't surface the idea
  36. of a "class descriptor" object of some sort as a formal part of the language?
  37.  
  38. I have not been using C++ extensively, but for the past couple years I have
  39. been using another C based OO paradigm.  I have found that there are a certain
  40. number of operations (yes, PARTICULARLY for debuggers) in which a formal idea
  41. of a type object with appropriate methods is indispensible.
  42.