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

  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:30 MDT
  5. Subject: Re: Novice? question: Designing for mul
  6. Sender: Notesfile to Usenet Gateway <notes@glas.apc.org>
  7. Message-ID: <1992Jul17.163022.28974@ucc.su.oz>
  8. References: <1992Jul9.144630.10863@clpd.kodak>
  9. Nf-ID: #R:1992Jul9.144630.10863@clpd.kodak:653025985:1992Jul17.163022.28974@ucc.su.oz:1135296309:001:2824
  10. Nf-From: extro.ucc.su.OZ.AU!maxtal    Jul 17 20:30:00 1992
  11. Lines: 73
  12.  
  13.  
  14. In article <rmartin.711299360@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  15. >maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:
  16. >
  17. >|In article <1992Jul14.122238.9500@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:
  18. >|>In article <rmartin.711047889@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  19. >|>>
  20. >|>>|    WARNING: You can't do this using either cfront or Borlandc,
  21. >|>>|    both have faults preventing use of virtual abstract bases.
  22. >|>>
  23. >|>>MAX: This is far too strong a statement.  There are indeed some
  24. >|>>limitations, especially where virtual bases are concerned.  But you
  25. >|>>CAN make mixin heirarchies quite successfully.
  26. >|>
  27. >|>    I don't agree. 
  28. >
  29. >|    Well, on re-reading, I would now change my comments:
  30. >
  31. >|    Yes, you can make mixin *heirarchies* without problems.
  32. >
  33. >|    But, that is almost an oxymoron: mixin is almost by
  34. >|    definition using DAGs, it explicitly requires
  35. >|    shared virtual bases to hook the implementations in,
  36. >|    so it would not be possible to have a mixin *heirarchy*,
  37. >|    mixin relies on 'sibling' virtual calls.
  38. >
  39. >But as I explained in a previous posting, mixin of pure virtual
  40. >functions through DAGs is not precluded, the derived class must simply
  41. >resolve the ambiguities by declaring the functions and routing them to
  42. >the appropriate base.  Inconvenient, but not a disaster.
  43.  
  44.     My point is not that mixin through DAGS is, or is not 
  45. *precluded*, but that mixin is ALWAYS through DAGS (otherwise
  46. it is not mixin).
  47.  
  48.     And there are no ambiguities PLEASE read the section
  49. in the ARM on name dominance, look at the examples
  50. of sibling calls given there, and THEN read the definition
  51. of abstract classes.
  52.  
  53.     See how it is a little fuzzy?
  54.  
  55.     See how it SHOULD read
  56.  
  57.     "An abstract class is one which, if it were instantiated,
  58.     would be subject to virtual calls to pure functions,
  59.     and therefore can't be instantiated. Any class for
  60.     which all virtual calls are to non-pure functions
  61.     is NOT abstract"
  62.  
  63. In other words: an abstract class is one with holes in it.
  64. A concrete class is one without holes.
  65.  
  66. If a class is derived from some base, and a virtual call
  67. though the base is resolved to some function in a class
  68. derived from the base, then the base virtual can be
  69. made pure (in this instance) without the most derived
  70. object having any holes and therefore it would remain concrete.
  71.  
  72. This whole issue was argued out before. I started it.
  73. Borland agrees it is a bug to be fixed. Others have
  74. confirmed that this makes sense. How else could
  75. you possibly interpret the definition of
  76. ABSTRACT class?
  77.  
  78.  
  79.  
  80. -- 
  81. ;----------------------------------------------------------------------
  82.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  83.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  84. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  85.  
  86.