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

  1. Xref: sparky comp.lang.c++:11227 comp.std.c++:893
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  4. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  5. Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
  6. Message-ID: <1992Jul21.150332.22301@ucc.su.OZ.AU>
  7. Sender: news@ucc.su.OZ.AU
  8. Nntp-Posting-Host: extro.ucc.su.oz.au
  9. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  10. References: <1992Jul17.154635.27331@ucc.su.OZ.AU> <1992Jul20.141712.4622@cadsun.corp.mot.com>
  11. Date: Tue, 21 Jul 1992 15:03:32 GMT
  12. Lines: 105
  13.  
  14. In article <1992Jul20.141712.4622@cadsun.corp.mot.com> shang@corp.mot.com writes:
  15. >In article <1992Jul17.154635.27331@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU  
  16. >(John MAX Skaller) writes:
  17. >>     Certainly there are het aggregates out there, say
  18. >> Windows 3.0 window lists. But the can be converted to C++
  19. >> objects without loss of type info: they don't have to
  20. >> be collected in the same form as they are presented to
  21. >> you.
  22. >>
  23. >
  24. >You need, at least, a pre-compiler to analize the type system and gather the  
  25. >information for this case. 
  26.  
  27.     If you try to use C++ in an evironment where the system
  28. must be dynamically extended with completely new types, you
  29. will certainly need run-time type info. In fact, you had better
  30. be able to incrementally compile and dynamically link as well.
  31. So you need a proper reflexive system.
  32.  
  33.     C++ is way off being able to do that, even if it had
  34. run-time type-info.
  35.  
  36.     Any how for this sort of facility:: one where you
  37. try to use C++ for something way outside its original purpose,
  38. and way outside the boundaries of any statically compiled
  39. system, well, yes, run-time type info is needed, and much
  40. much more.
  41.  
  42.     But you will note: we're not talking about mere
  43. downcasting here---*that* was the original issue.
  44. Here you're talking about dynamism---dynamic typing,
  45. dynamic compilation, dynamic loading, etc etc---
  46. all those things that Lisp and Stalk already do,
  47. I might add.
  48.  
  49.  
  50. >Let me give you some more examples. (1) OO operating  
  51. >systems written in C++: most systems must have their own pre-compiler that  
  52. >gathers the type information in order to provide a high level OO user  
  53. >interface. (2) OO database systems: they must have their own languages, at  
  54. >least a pre-compiler if they chose C++ as their master language, and most of  
  55. >the work for the pre-compiler is to gather the type information. 
  56.  
  57.     Here the precompiler is a nasty compromise.  A proper
  58. reflexive (self-extensible) system is what is really needed.
  59.  
  60. >And see  
  61. >another good example that Jonathan Robie gives us:
  62. >
  63. >In article <5W0422J@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie)  
  64. >writes:
  65. >> Think of stream I/O.  Don't you feel stupid coding an << operator for
  66. >> each type you want to be able to print?  An intelligent stream facility
  67. >> would be able to print any object with a sensible default format which
  68. >> could optionally include the name and type of each field.  Try to code
  69. >> this without run time information.  Since the I/O stream is coded first
  70. >> and can impose no restrictions on user objects I do not know of any way
  71. >> to solve this without adding my own precompiler.
  72. >> 
  73.  
  74.     Well, in this case there is no need at all for dynamic typing,
  75. a mere virtual function returning a string does the job just fine.
  76. >
  77. >In the same article <1992Jul17.154635.27331@ucc.su.OZ.AU>  
  78. >maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  79. >> Lets take feeding of animals. You must spec. the problem better.
  80. >> Does each animal know the types (finite list) of food they eat?
  81. >> E.g, you have list of base classes for each animal.
  82. >> 
  83. >> Now you have list of animals and list of foods, and feed each
  84. >> available food to animal until food is eaten. Is this
  85. >> what you want?
  86. >> 
  87. >>
  88. >
  89. >No, never. What I want is a spec.-- a spec. of a food type which is dependent  
  90. >on the animal type, and such dependency can be checked statically at compile  
  91. >time.
  92.  
  93.     Sure, but I don't understand *exactly* what you mean.
  94. I think you will have trouble formulating the problem.
  95. The reason I say this is that in general the solution
  96. requires multiple dispatch, in other words, a matrix of
  97. animal x food entries.
  98.  
  99.     Can you *reduce* the problem to less than a matrix?
  100.  
  101. >
  102. >David Shang
  103. >
  104. >
  105. >
  106. >> -- 
  107. >> ;----------------------------------------------------------------------
  108. >>         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  109. >>     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  110. >> ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  111.  
  112.  
  113. -- 
  114. ;----------------------------------------------------------------------
  115.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  116.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  117. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  118.