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

  1. Xref: sparky comp.lang.c++:11777 comp.std.c++:994
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!netmbx!jrobie
  4. From: jrobie@netmbx.netmbx.de (Jonathan Robie)
  5. Subject: Re: Language extensions for run-time type identification
  6. Organization: netmbx, Berlin, Germany
  7. Date: Thu, 30 Jul 1992 07:47:54 GMT
  8. Message-ID: <2XK58WG@netmbx.netmbx.de>
  9. References: <BryFLI.Hz2@world.std.com> <1992Jul29.192054.22533@cadsun.corp.mot.com>
  10. Lines: 56
  11.  
  12. shang@corp.mot.com (David (Lujun) Shang) writes:
  13.  
  14. >In article <BryFLI.Hz2@world.std.com> wmm@world.std.com (William M Miller)  
  15. >writes:
  16. >function.
  17.  
  18. >> The challenge, then, for those who view RTTI-via-vtable as
  19. >> insufficient is to provide *concrete* counterexamples to this
  20. >> assumption: applications where derived-to-base casting does occur
  21. >> without the need for virtual functions and for which RTTI would
  22. >> nevertheless be useful.  Are there such applications?
  23. >> 
  24.  
  25. The assumption here is that RTTI should be provided only as a means
  26. of safe downcasting within domestic systems.  That is obviously nice,
  27. but does nothing to help implement a variety of general purpose tools
  28. which need more information.
  29.  
  30. >  
  31. >And I'm sure many OO database and OS people can tell more.
  32.  
  33. Well, the biggest problem for OO databases is that the current RTTI
  34. proposal does not give us enough info even for classes *with* virtual
  35. tables.
  36.  
  37. A less serious problem: it seems silly to force our users to add
  38. virtual methods in order to store a class in the database.
  39.  
  40. So far I don't think the current RTTI proposal will affect us at all.
  41. We will continue to use our precompiler.  I would like to see a better
  42. proposal which would allow us to throw our precompiler away.
  43.  
  44. >Since OO technique is aimed mainly to developing large, complex and  
  45. >cooperative systems, C++, as general purposed OO language, should at least  
  46. >cover some main application areas.
  47.  
  48. Absolutely!  The general purpose tools which fit so well into the C++
  49. programming environment are precisely those which need RTTI.
  50.  
  51.  
  52. Jonathan
  53.  
  54. ===========================================================================
  55.  
  56. Jonathan Robie        jrobie@netmbx.UUCP
  57. Arnold-Zweig-Str. 44    jrobie@netmbx.in-berlin.de
  58. O-1100 Berlin        
  59. Deutschland        Phone:  +37 (2) 472 04 19  (Home, East Berlin)
  60.                 +49 (30) 342 30 66 (Work, West Berlin)
  61.  
  62.  
  63. -- 
  64. Jonathan
  65.  
  66. ===========================================================================
  67.  
  68.