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

  1. Xref: sparky comp.lang.c++:11504 comp.std.c++:947
  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: <1992Jul24.192207.15267@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: <1992Jul22.022218.1115@cadsun.corp.mot.com> <1992Jul23.154254.5306@ucc.su.OZ.AU> <1992Jul24.143359.3602@advtech.uswest.com>
  11. Date: Fri, 24 Jul 1992 19:22:07 GMT
  12. Lines: 124
  13.  
  14. In article <1992Jul24.143359.3602@advtech.uswest.com> glw@io.uswest.com (Glenn Williams) writes:
  15. >>(John MAX Skaller) writes:
  16. >>
  17. >>    Given the need to do downcasting, to do it safely run-time
  18. >>type information is required. But I am arguing it is not necessary
  19. >>to downcast. So the question of needing run-time type info to
  20. >>do it doesn't arise.
  21. >>
  22. >>We design our systems properly in the first place, and then the need
  23. >>to downcast never arises, when our thoughts wander in that 
  24. >>direction one can be sure we are not thinking virtuously,
  25. >>and perhaps the design itself is flawed.
  26. >
  27. >Ok, let's have an example of a properly designed system. 
  28.  
  29.     I can of course give any number of systems not using
  30. downcasting --- LOTS of code I have written for example.
  31.  
  32.     But that wont PROVE anything. You have to give me
  33. an example of a system that uses downcasting and then I'll
  34. show how to write it without downcasting.
  35.  
  36.     Please restrict examples to domestic systems, since
  37. I already agree all bets are off for foreign systems and
  38. also for introspective ones like, say, debuggers, OODBMS,
  39. etc.
  40.  
  41.     Lets agree for example to restrict ourselves to
  42. text input and output and no disk storage. Lets agree
  43. that the program must handle a fixed number of types.
  44. And that it reads text in, does some calculations,
  45. and then prints the answers.
  46.  
  47.     Such a program creates ALL the objects, manipulates
  48. them, and then it terminates.
  49.  
  50. >
  51. >>    Inother words, in a *domestic* system, any apparent 
  52. >>need for downcasting should be used as an indicator of flawed design.
  53. >>
  54. >What is the basis for your conclusions?
  55.  
  56.     There are two reasons.
  57.  
  58.     1) Its NEVER necessary. Because you CREATED all the objects
  59.     in the first place, you know their types at that point in
  60.     time, agreed?
  61.  
  62.     So if you want to find out the type of an object, you have
  63.     forgotten something you once knew---and that is a design
  64.     flaw if you needed to know the type.
  65.  
  66.     2) The second reason is that downcasting---indeed ANY casting
  67.     and not downcasting in particular---cheats the type system
  68.     by giving you access to hidden implementation details.
  69.  
  70.     I dont want to write a book on why one should want to hide
  71.     implementation details :-) I assume you know about this
  72.     and agree it is proper.
  73.  
  74.     But the derived type of a base IS PRECISELY implementation
  75.     details of the base class.
  76.  
  77.     Polymorphism, though virtual functions, provides the
  78.     CORRECT and safe way to access the particular
  79.     implementation of an object---by virtual function calls.
  80.  
  81.     So ESPECIALLY in the case of pointers to bases,
  82.     casting is unnecessary and bad. There is already
  83.     a proper way to access the derived class.
  84.  
  85.     If you cant figure how to do what you want via the base
  86.     class---it is a design flaw.
  87. >
  88. >You have stated all this before, and every time you do, you fail to provide
  89. >any examples of how you would design without downcasting. 
  90. >
  91. >So, as I asked for earlier, let's have an example of a properly
  92. >designed system.
  93. >
  94.  
  95.     Sure. But you have to tell me what problem you want to solve,
  96. else I'll just give you a copy of my, um lets see, matrix clas,
  97. or perhaps my network emulator, or perhaps my chemical plant
  98. Quantative Risk Analysis Program.
  99.  
  100.     Believe me, in the QRA program I was tempted to downcast.
  101. Apparently some problems couldn't be solved without it. But,
  102. because it used dynamic linkage, I COULDN'T cheat by downcasting,
  103. even if I wanted to, since athe main program had no idea
  104. what derived classes would be used (they are loaded dynamically
  105. under user control). By not using downcasting I am
  106. GUARRANTEED that ANY proper implementation of the
  107. various base classes could be used.
  108.  
  109.     As soon as I put even one downcast in, then that
  110. module MUST be loaded. And that defeats the design spec
  111. of having ALL the components dynamically linkable.
  112.  
  113.     QRA models hazards at chemical plants. The objects
  114. include hazardous chemicals, and various types of fixtures
  115. like tanks and pipes. The fixtures are 'drawn' on a map
  116. using the mouse.
  117.  
  118.     Chemicals are put in the containers, and various
  119. leaks occur, fires start, toxic materials are dispersed.
  120. The accumulated affects over a million years are
  121. then plotted on a map, and the results sold to
  122. the chemical companies (for safety reasons, or because
  123. governments require Environmental Impact Statements
  124. to be done).
  125.  
  126.     The hardest part of this system was to have a few
  127. abstractions representing 'container', 'chemical',
  128. and 'phenomena' (leak, fire, etc).
  129.  
  130.     The actual numerical modelling of fires was easy,
  131. because the client supplied the algorithm :-)
  132. -- 
  133. ;----------------------------------------------------------------------
  134.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  135.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  136. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  137.