home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11269 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.1 KB
  1. Xref: sparky comp.lang.c++:11269 comp.std.c++:904
  2. Path: sparky!uunet!ogicse!decwrl!world!wmm
  3. From: wmm@world.std.com (William M Miller)
  4. Newsgroups: comp.lang.c++,comp.std.c++
  5. Subject: Re: Language extensions for run-time type identification
  6. Message-ID: <BrrAvo.EFA@world.std.com>
  7. Date: 21 Jul 92 20:42:59 GMT
  8. Article-I.D.: world.BrrAvo.EFA
  9. References: <TMB.92Jul20182052@arolla.idiap.ch> <1992Jul20.220534.1365@cadsun.corp.mot.com> <14ft2uINNjh4@agate.berkeley.edu>
  10. Organization: Software Emancipation Technology, Inc.
  11. Lines: 30
  12.  
  13. In article <14ft2uINNjh4@agate.berkeley.edu>, Joe Buck writes:
  14. > * the virtual impossibility of designing a more general solution that does
  15. >   not break compatibility with C structs (a requirement that may be
  16. >   meaningless to theoretical folks but that is nevertheless vital).
  17. >   This constraint forbids adding any data to the object of any kind.
  18.  
  19. I presented such a solution in my position paper on runtime type
  20. information given in a technical session at the March, 1991 X3J16
  21. meeting.  It is somewhat more costly in time and space than the vtable
  22. approach, so it would probably require as a practical matter that both
  23. mechanisms be implemented, fast for classes with virtual functions and
  24. slow(er) for other classes.
  25.  
  26. The issue is whether complete generality is sufficient justification
  27. for complicating the implementation and adding some runtime expense
  28. (which would be present even in programs that did not use RTTI
  29. facilities, unless turned off by command line or #pragma).  I assume
  30. from the fact that my suggestion was not adopted into the current
  31. proposals that the general consensus was that complete generality was
  32. not sufficient justification.  I don't know how to evaluate the
  33. relative importance of these factors.
  34.  
  35. > I could also argue the other way: for a debugger, it isn't enough to
  36. > identify all class objects.  I also need to be able to identify the
  37. > types of any int, double, pointer, or reference variables.
  38.  
  39. This also turns out not to be terribly difficult.  Again, the issue is
  40. trading off utility versus cost.
  41.  
  42. -- William M. Miller, wmm@world.std.com
  43.