home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!fuug!demos!kiae!glas!demos!ucc.su.oz!extro.ucc.su.OZ.AU!maxtal
- From: maxtal@extro.ucc.su.OZ.AU
- Newsgroups: comp.lang.c++
- Date: 17 Jul 92 20:30 MDT
- Subject: Re: Novice? question: Designing for mul
- Sender: Notesfile to Usenet Gateway <notes@glas.apc.org>
- Message-ID: <1992Jul17.163022.28974@ucc.su.oz>
- References: <1992Jul9.144630.10863@clpd.kodak>
- Nf-ID: #R:1992Jul9.144630.10863@clpd.kodak:653025985:1992Jul17.163022.28974@ucc.su.oz:1135296309:001:2824
- Nf-From: extro.ucc.su.OZ.AU!maxtal Jul 17 20:30:00 1992
- Lines: 73
-
-
- In article <rmartin.711299360@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
- >maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:
- >
- >|In article <1992Jul14.122238.9500@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:
- >|>In article <rmartin.711047889@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
- >|>>
- >|>>| WARNING: You can't do this using either cfront or Borlandc,
- >|>>| both have faults preventing use of virtual abstract bases.
- >|>>
- >|>>MAX: This is far too strong a statement. There are indeed some
- >|>>limitations, especially where virtual bases are concerned. But you
- >|>>CAN make mixin heirarchies quite successfully.
- >|>
- >|> I don't agree.
- >
- >| Well, on re-reading, I would now change my comments:
- >
- >| Yes, you can make mixin *heirarchies* without problems.
- >
- >| But, that is almost an oxymoron: mixin is almost by
- >| definition using DAGs, it explicitly requires
- >| shared virtual bases to hook the implementations in,
- >| so it would not be possible to have a mixin *heirarchy*,
- >| mixin relies on 'sibling' virtual calls.
- >
- >But as I explained in a previous posting, mixin of pure virtual
- >functions through DAGs is not precluded, the derived class must simply
- >resolve the ambiguities by declaring the functions and routing them to
- >the appropriate base. Inconvenient, but not a disaster.
-
- My point is not that mixin through DAGS is, or is not
- *precluded*, but that mixin is ALWAYS through DAGS (otherwise
- it is not mixin).
-
- And there are no ambiguities PLEASE read the section
- in the ARM on name dominance, look at the examples
- of sibling calls given there, and THEN read the definition
- of abstract classes.
-
- See how it is a little fuzzy?
-
- See how it SHOULD read
-
- "An abstract class is one which, if it were instantiated,
- would be subject to virtual calls to pure functions,
- and therefore can't be instantiated. Any class for
- which all virtual calls are to non-pure functions
- is NOT abstract"
-
- In other words: an abstract class is one with holes in it.
- A concrete class is one without holes.
-
- If a class is derived from some base, and a virtual call
- though the base is resolved to some function in a class
- derived from the base, then the base virtual can be
- made pure (in this instance) without the most derived
- object having any holes and therefore it would remain concrete.
-
- This whole issue was argued out before. I started it.
- Borland agrees it is a bug to be fixed. Others have
- confirmed that this makes sense. How else could
- you possibly interpret the definition of
- ABSTRACT class?
-
-
-
- --
- ;----------------------------------------------------------------------
- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au
- Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
- ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
-
-