Path: utzoo!censor!geac!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!uwm.edu!bionet!ames!vsi1!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: <27C95D3A.1715@tct.uucp> Date: 25 Feb 91 18:53:46 GMT Article-I.D.: tct.27C95D3A.1715 References: <1991Feb19.214327.13930@gpu.utcs.utoronto.ca> <27C2D973.3C1B@tct.uucp> Organization: Teltronics/TCT, Sarasota, FL Lines: 56 According to dsouza@optima.cad.mcc.com (Desmond Dsouza): >... only requires that (x.class) be of type, say, "ClassId", which >supports "ClassId == ClassId" for class identity, and possibly >"ClassId <= ClassId" for sub-class checks. ... It does not require >a unique program-wide integer per class. I stand corrected. >It is reasonable for x.class to be a virtual function call ONLY if >class X already has virtual functions ... Hence, you do not have to >add virtual-ness to otherwise non-virtual classes. I stand corrected^2. It wouldn't be the efficiency hog I had claimed. Nevertheless, I have a hard time supporting the feature. Every time I hear "typeof(foo)" I see masses of poorly-written Smalltalk: "foo isTypeOf: OrderedCollection or: foo isTypeOf: UnorderedCollection..." >Here are a few examples where you need to know the type of an object: "Need?" That's a red flag for me... :-) >1. Persistent objects: When reading in one of these from disk, you > need to know what constructor to call. Hence you need to encode in > the persistent image the ClassId of the object. Presumably, a well-designed class hierarchy will use a virtual function to store objects; and a virtual function by definition will already know the exact type of the object it is storing. >2. You have an interactive system where a mouse-weilding user > dynamically configures objects together. You need to check the > configuration for validity ... ClassID would be a useful tool in such code, but it is by no means necessary. For example, each class can have virtual functions along the lines of "int can_be_owned()". And do you want J. Random Coder making decisions like "if x is a Widget, but not a FooWidget..." >3. Almost any application related to a programming environment: > debuggers, smart re-compilers, ... I can see it for debugging. But the extra cost of the feature is not something I'd want to inherit permanently in my delivered executable. And I must say that debugging alone is a little thin as justification for a language feature with run-time costs. >C++ cast restrictions on virtual-base classes (cannot cast from >virtual base to derived) could be removed if the compiler made some >of this information available at run-time! But you can always write a virtual function that does the cast. -- 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)