home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.lang.c++:11476 comp.std.c++:939
- Newsgroups: comp.lang.c++,comp.std.c++
- Path: sparky!uunet!gatech!destroyer!gumby!wupost!sdd.hp.com!decwrl!mips!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
- From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
- Subject: Re: Language extensions for run-time type identification
- Message-ID: <1992Jul24.142452.756@ucc.su.OZ.AU>
- Sender: news@ucc.su.OZ.AU
- Nntp-Posting-Host: extro.ucc.su.oz.au
- Organization: MAXTAL P/L C/- University Computing Centre, Sydney
- References: <1992Jul21.094204.20100@mole-end> <1992Jul22.150330.6160@cadsun.corp.mot.com> <1992Jul23.183041.147@uunet.uu.net!mole-end>
- Date: Fri, 24 Jul 1992 14:24:52 GMT
- Lines: 45
-
- In article <1992Jul23.183041.147@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
- >In article <1992Jul22.150330.6160@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
- >> In article <1992Jul21.094204.20100@mole-end> mat@mole-end writes:
- >> >
- >> > The assumption underlying the decision to include only classes with
- >> > virtual functions is that a class that has no polymorphic behavior
- >> > whatsoever (not even a virtual destructor) cannot be used in any way
- >> > that is both safe and interesting even with the proposed runtime type
- >> > support. Can you refute this assumption?
- >> > --
- >
- >
- >> First of all and to be specific to C++, it is the class hierarchy, or
- >> inheritance and the polymorphic pointers that lead to the necessity of
- >> run time type checking. It is not the virtual behaviors of a class.
- >> We still need run time type check even if we disallow any virtual behaviors
- >> in C++. Therefore, the assumption is laid on the wrong ground.
- >
- >But without virtualization (polymorphic behavior) derivation is effectively
- >useless. There is no reason to code inheritance without providing for
- >virtualization. Then the case which you mention is of no use unless and
- >until it is provided with RTTI; providing RTTI for it using reasonable
- >and economical mechanisms would violate certain assumptions that C++ allows
- >its users to make (C struct compatability).
-
- But I would make that argument backwards.
-
- One often wants het. aggregates of unrelated types.
- Actually, these are aggregates of the *same* type,
- namely, the union of the unrelated types.
-
- On the otherhand, polymorphism is the mechanism by which
- the derived type NEED NOT BE KNOWN. Indeed, if we are to preserve
- the open/closed principle, MUST NOT BE KNOWN.
-
- So you (well, X3) is considering using RTTI in
- precisely the case it is not needed, and not supplying it
- when it actually could be useful :-)
-
-
- --
- ;----------------------------------------------------------------------
- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au
- Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
- ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
-