Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!daver!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.std.c++ Subject: Re: type/member tags (was Re: asking an object for its type) Message-ID: <27C2D973.3C1B@tct.uucp> Date: 20 Feb 91 20:17:55 GMT References: <65451@brunix.UUCP> <1991Feb19.191731.4137@pa.dec.com> <1991Feb19.214327.13930@gpu.utcs.utoronto.ca> Organization: Teltronics/TCT, Sarasota, FL Lines: 65 According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >PROBLEM accessing features that do not exist on all of the possible types of > a passed object, e.g. "is this a circle of diameter > 30 ?" > >TODAY explicit type tag > - inconsistent across user programs > - cannot be added to imported classes Bzzt. You forgot: TODAY.2 virtual member function that does the operation or reports failure and/or raises an exception. - uses language features already available - doesn't require client changes when class hierarchy changes >SOL.2 .class member, similar to .this member This solution would require a unique program-wide integer that would represent each class. (Can you say Objective-C? Ugh.) It would also impose the space overhead of virtual functions on classes that do not need it. It would further make programs dependendent on the details of inheritance. ("Let's see, I want all subclasses of foo except bar, um, they're larry, moe, curly..." Double ugh.) >SOL.3 conditional cast, similar to catch Eliminates the knowledge-of-inheritance problem, but cost-of-virtual and unique-class-id problems are still there. >SOL.4 as above, only testing for presence of members, not name of classes How do you know that "circle.size()" and "building.size()" are in any way related to each other? You don't. Member name is meaningless without some indication of which "size()" is the Right One. So once you figure out which one is the Right One, make it virtual. Presto. >It just isn't a controversy, except for Bjarne it seems. At least I >haven't seen any evidence of someone else saying you should never see >the type of an object. Count me in with Bjarne. You, the programmer, never really want to know the type. You may think you want to know the type, but why? So you can know if a feature is available. So make the feature a virtual function and be done with it. >I hope ANSI C++ doesn't end up as a half-baked collision of object-oriented >dogma and C dogma. Why change now? :-) >The mere fact that compiler developers are including it is a strong >sign of user demand, and it is obviously not ignorant demand. "Obviously?" It's not obvious to me. >There are such things as optimizing compilers, which C-heads usually have >never heard of because the language's low-level constructs are so pervasive >and hard to optimize. I know all about optimizers, thank you very much. They are utterly irrelevant to the issues of type knowledge. -- Chip Salzenberg at Teltronics/TCT , "It's not a security hole, it's a SECURITY ABYSS." -- Christoph Splittgerber (with reference to the upage bug in Interactive UNIX and Everex ESIX)