Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!uunet!pdn!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.std.c++ Subject: Re: type/member tags Message-ID: <27D3E544.619A@tct.uucp> Date: 5 Mar 91 18:36:51 GMT References: <27C95D3A.1715@tct.uucp> <4201@lupine.NCD.COM> <1399@culhua.prg.ox.ac.uk> Organization: Teltronics/TCT, Sarasota, FL Lines: 34 According to bill@robots.oxford.ac.uk (Bill Triggs): >Type info is *essential* for safe down-casting. The alternative >of pushing all Derived functions (and implicitly members) into >the Base -- either as full implementations or as empty or >error-calling stubs -- is simply laughable... "Laughable" is not a very helpful description. Specific objections, please. Note that downcasting to Derived* can itself be _one_ virtual function of Base. >Creation of an instance of an implicitly specified class.... >It seems that an appropriately global `class-designator' is >indispensable for this, whether string or global address or >global enumeration constant ... The class name is already guaranteed to be unique (name equivalence and all that). What need of more? >... appropriate `static Class* Class::' or `friend Class*' >new_object() or read_object(), parse_object() functions... What's missing from a virtual function "Base *Base::clone() const"? >... Switch()-ing on type ought to be possible. I fail to see why such a feature should be supported, when the difficulties of producing a global (multi-module) class->integer equivalence are so well known. -- Chip Salzenberg at Teltronics/TCT , "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre