home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12717 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  4.0 KB
  1. Path: sparky!uunet!mcsun!sunic!hagbard!loglule!jbn
  2. From: jbn@lulea.trab.se (Johan Bengtsson)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Downcasting (was: Re: run-time type checking)
  5. Message-ID: <4858@holden.lulea.trab.se>
  6. Date: 21 Aug 92 11:56:42 GMT
  7. References: <1992Aug21.004033.15204@ucc.su.OZ.AU>
  8. Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
  9. Lines: 107
  10. X-Newsreader: Tin 1.1 PL4
  11.  
  12. maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  13. : In article <4847@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
  14. : 
  15. : I certainly dont have a more convincing argument
  16. : than the example I gave before:
  17. : 
  18. :     class X { 
  19. :     protected: 
  20. :         int i;
  21. :     public: 
  22. :         int get()const {return i;}
  23. :         X(int j) : i(j) {}
  24. :     };
  25. : 
  26. :     class Y : public virtual X {
  27. :     public: 
  28. :         Y(int j) : X(j) {}
  29. :         void set(int j) { i=j;}
  30. :     };
  31. : 
  32. :     f(X&);
  33. :     Y aY;
  34. :     f(Y);
  35. : 
  36. : I am disturbed by the fact that f can modify its X object when the
  37. : interface says it cant.
  38.  
  39. ****    I agree that this makes static typechecking more "loose".
  40.  
  41.     I think this looseness is needed, because it can be
  42.     difficult to write programs that never looses significant type
  43.     information, especially if you are using (inheriting from)
  44.     other peoples classes.
  45.  
  46.     Cast-downs are dirty (but sometimes quick) solutions
  47.     when you find you have lost significant type information.
  48.  
  49. : >    I think we agree on the need to sometimes do controlled downcasts.
  50. :     
  51. :     Dont know what you mean by 'sometimes'. I propose no
  52. : downcasting, ever.
  53.  
  54. ****    Fine, but note that, if you define X::operator Y* (),
  55.     then you are in fact suppporting controlled down-casting to Y.
  56.  
  57. :     Downcasting is an ABUSE of the concept of polymorphism,
  58. : it tries to mix up the ideas of polymorphism with heterogeneity.
  59. : These are totally different mechanisms conceptually that unfortunately
  60. : both can be implemented using inheritance.
  61.  
  62. ****    I note that the combination of polymorphism and heterogeneity
  63.     weakens the restrictions on what can be done with a polymorphic
  64.     reference.
  65.  
  66.     You have a point that a function that down-casts its arguments
  67.     is _always_ bad.
  68.  
  69.     On the other hand, down-casting a return value is not so bad:
  70.  
  71.     void g() {
  72.        Base& b = findObjectUsingCommercialLibraryThatOnlyKnowsBase();
  73.        MyDerived& d = refcast(MyDerived,b);
  74.     }
  75.  
  76.     In this case I "know" that I have previously stored an object
  77.     of type "MyDerived", but this type was not known when
  78.     the library function was written.  Templates can surely help,
  79.     but my point is that this particular use of down-casting
  80.     does not break polymorphism the way you describe it
  81.     I don't think the library function should make any assumption
  82.     about what might be done to the returned object, if it
  83.     indeed was intended to support future inheritance.
  84.  
  85.     Also, it is likely that people will run into the situation
  86.     where a template could have been used to avoid the need for
  87.     a downcast, but wasn't.
  88.  
  89. :     I see the problem is that because you can add arbitrary
  90. : derived classes polymorphically people assume they can arbitrary
  91. : classes heterogeneically too.
  92.  
  93. ****    They can, but normally shouldn't.
  94.  
  95. : >    [...]You can't find out which
  96. : >    derived classes override a virtual by inspecting the
  97. : >    base class.
  98. : 
  99. :     Of course not. You dont CARE how or whether the derived class
  100. : defines the virtual. Indeed you MUSTNT KNOW. And you dont NEED to know.
  101. : That lack of knowledge is power. Only by denying all knowledge
  102. : can you claim arbitrariness, and only with arbitrariness do you
  103. : have openness.
  104.  
  105. ****    These are good points.
  106.  
  107.     Which brings us to the point where I jumped into this discussion:
  108.  
  109.     Declaring explicit operators for down-casting ( X::operator Y*() )
  110.     gives the base class too much knowledge.  If you wish to
  111.     do down-casting at all, it is more "open" to do direct
  112.     down-casting, without the base class knowing about it.
  113.  
  114. -- 
  115. --------------------------------------------------------------------------
  116. | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
  117. | jbn@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490              |
  118. --------------------------------------------------------------------------
  119.