home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11634 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  3.1 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!pacbell.com!UB.com!igor!thor!rmartin
  2. From: rmartin@thor.Rational.COM (Bob Martin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Novice? question: Designing for mul
  5. Message-ID: <rmartin.712271000@thor>
  6. Date: 27 Jul 92 21:03:20 GMT
  7. References: <1992Jul9.144630.10863@clpd.kodak> <1992Jul17.163022.28974@ucc.su.oz>
  8. Sender: news@Rational.COM
  9. Lines: 64
  10.  
  11. maxtal@extro.ucc.su.OZ.AU writes:
  12.  
  13.  
  14. |In article <rmartin.711299360@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  15. |>
  16. |>But as I explained in a previous posting, mixin of pure virtual
  17. |>functions through DAGs is not precluded, the derived class must simply
  18. |>resolve the ambiguities by declaring the functions and routing them to
  19. |>the appropriate base.  Inconvenient, but not a disaster.
  20.  
  21.  
  22. |    And there are no ambiguities PLEASE read the section
  23. |in the ARM on name dominance, look at the examples
  24. |of sibling calls given there, and THEN read the definition
  25. |of abstract classes.
  26.  
  27. As I explained in my previous posting, the ambiguity is in the ARM.
  28. It does not make it clear whether inheriting a pure virtual function
  29. from one side of the DAG is overriden by an impure virtual function on
  30. the other side of the DAG.
  31.  
  32. Oh it makes sense to do this, maybe.  But the ARM leaves the question
  33. open.  
  34.  
  35. |This whole issue was argued out before. I started it.
  36. |Borland agrees it is a bug to be fixed. Others have
  37. |confirmed that this makes sense. How else could
  38. |you possibly interpret the definition of
  39. |ABSTRACT class?
  40.  
  41. An abstract class is a class with a pure virtual function, either
  42. specified or inherited.  If you are inheriting from two classes, one
  43. of which has a pure virtual, and the other has the same virtual
  44. function, but impure, should be base be abstract or not?  Is the pure
  45. virtual inherited, or are impure virtuals inherited preferentially to
  46. pure virtuals.  
  47.  
  48. I am leaning with your interpretation, that the impure should be
  49. inherited preferentially, and that the class should not be abstract.
  50. But I don't think the issue is as clear cut as you claim.  For
  51. example, I could pose the following argument:
  52.  
  53. In any case where a pure virtual and an impure virtual can be
  54. inherited through separate branches of the DAG, the pure virtual
  55. should have preference since it makes an unambiguous statement that
  56. the function should be overridden in the *derived* class.  Since
  57. inheriting the impure is not the same as overriding, it should not be
  58. inherited.
  59.  
  60. Maybe you don't agree with that argument.  I am not sure I do either.
  61. But it does demonstrate that the issue could be debated.
  62.  
  63.  
  64.  
  65. |-- 
  66. |;----------------------------------------------------------------------
  67. |        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  68. |    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  69. |;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  70. --
  71. +---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
  72. | rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
  73. |     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
  74. +----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |
  75.