home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11360 < prev    next >
Encoding:
Text File  |  1992-07-22  |  3.8 KB  |  102 lines

  1. Path: sparky!uunet!mcsun!fuug!demos!kiae!glas!demos!ucc.su.oz!extro.ucc.su.OZ.AU!maxtal
  2. From: maxtal@extro.ucc.su.OZ.AU
  3. Newsgroups: comp.lang.c++
  4. Date: 17 Jul 92 20:17 MDT
  5. Subject: Re: Novice? question: Designing for mul
  6. Sender: Notesfile to Usenet Gateway <notes@glas.apc.org>
  7. Message-ID: <1992Jul17.161720.28511@ucc.su.oz>
  8. References: <1992Jul9.144630.10863@clpd.kodak>
  9. Nf-ID: #R:1992Jul9.144630.10863@clpd.kodak:653025985:1992Jul17.161720.28511@ucc.su.oz:-1685440123:001:3370
  10. Nf-From: extro.ucc.su.OZ.AU!maxtal    Jul 17 20:17:00 1992
  11. Lines: 89
  12.  
  13.  
  14. In article <rmartin.711298357@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  15. >maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:
  16. >|>
  17. >|>|    WARNING: You can't do this using either cfront or Borlandc,
  18. >|>|    both have faults preventing use of virtual abstract bases.
  19. >|>
  20. >|>MAX: This is far too strong a statement.  There are indeed some
  21. >|>limitations, especially where virtual bases are concerned.  But you
  22. >|>CAN make mixin heirarchies quite successfully.
  23. >
  24. >|    I don't agree. To use mixin properly you need orthogonal
  25. >|classes. It is not possible to define an abstract 'diamond'
  26. >|in Borlandc and use it. Test program is included right here.
  27. >
  28. >|// RE Abstract Classes
  29. >|// some compilers work and others fail when #define KLUDGE is 
  30. >|// commented out. Borlandc says D is abstract.
  31. >|// CLEARLY it is not.
  32. >|// However rewiting rules in ARM are not clear.
  33. >|// It is essential for "mix-in" programming that D is concrete.
  34. >|// as far as I know:
  35. >|//  Broken: BorlandC (MY compiler), cfront (AT&T)
  36. >|//  Work  : GNU++, MC7 (Microsoft)
  37. >|//
  38. >|#define KLUDGE
  39. >|#ifndef KLUDGE
  40. >|class V {public: virtual void f()=0; virtual void g()=0;};
  41. >|#else
  42. >|class V {public: virtual void f(){printf("ERROR V::g\n");} 
  43. >|    virtual void g(){printf("ERROR V::g\n");}};
  44. >|#endif
  45. >|class A1 : public virtual V {public: void f(){printf("A1::f\n");}};
  46. >|class A2 : public virtual V {public: void g(){printf("A2::g\n");}};
  47. >|class D : public A1, public A2 {};
  48. >|int main()
  49. >|{
  50. >|    D* d=new D;
  51. >|    A1 * a1=d;
  52. >|    A2 * a2=d;
  53. >|    V * v = d;
  54. >|    d->f(); a1->f(); a2->f(); v->f();
  55. >|    d->g(); a1->g(); a2->g(); v->g();
  56. >|}
  57. >
  58. >Yes, this is a problem.  There are ambiguities which are difficult to
  59. >resolve when trying to fit a jigsaw set of methods together through
  60. >MI.  Should pure virtual functions be preferentially overridden by
  61. >implemented virtual function muliply inherited from a sibling?  I am
  62. >sure that a counter example could be conceived.
  63.  
  64.     I am sorry, but you are quite wrong. There is NO PROBLEM with
  65. overriding virtual functions. There is NO AMBIGUITY in the choice
  66. of the correct function here: read ARM.
  67.  
  68.     The fact that it works when KLUDGE is defined PROVES that.
  69. The problem is much simpler: Borland thinks D is abstract
  70. and will not instantiate it, it is wrong. The definition
  71. is ARM is misleading, but there can be no other sensible
  72. interpretation.
  73.  
  74. >
  75. >Still, this does not raise a hopless issue.  Your class D simply needs
  76. >to be implemented in such a way that it declares f and g and calls the
  77. >correct functions.  i.e. 
  78. >    D::f() {A1::f();}
  79. >    D::g() {A2::g();}
  80. >
  81. >This is something of a pain, but it is necessitated by the current
  82. >rules of multiple inheritance.
  83. >
  84.  
  85.     No, it works PROPERLY with KLUDGE defined. There is NO problem
  86. resolving the virtual calls. D is concrete, not abstract,
  87. Borland is simply wrong.
  88.  
  89.     Your solution is a pain in the proverbial but will force
  90. D to be concrete. So will providing dummy bodies as I have
  91. done above. Sometimes your solution is better, however.
  92.  
  93.     The best solution is for Borland and AT&T to fix their
  94. broken compilers: Microsoft does not have this problem.
  95.  
  96. -- 
  97. ;----------------------------------------------------------------------
  98.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  99.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  100. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  101.  
  102.