Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.std.c++ Subject: Re: type/member tags (was Re: asking an object for its type) Message-ID: <70877@microsoft.UUCP> Date: 25 Feb 91 20:56:43 GMT References: <65451@brunix.UUCP> <1991Feb19.191731.4137@pa.dec.com> <1991Feb19.214327.13930@gpu.utcs.utoronto.ca> <27C2D973.3C1B@tct.uucp> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 42 In article dsouza@optima.cad.mcc.com (Desmond Dsouza) writes: | |This topic does come up quite often, doesn't it? Yep. Seems like the C++ world is solidly in two camps on this issue. One camp says any notion of run-time type is bad, and we're not going to support it. The other camp says that in some situations some notions of run-time type are useful, and C++ ought to have some good way to support it. My claim is that if some notions of run-time type are not in the language, then a lot of C++ vendors are simply going to go out and implement their own, incompatible notions of run-time type. I suggest that run-time type info can be specified as part of the language, can be done in a way that classes that don't want to use such a feature pay no price, and that run-time type info can be implemented in compilers at fairly low cost. Therefore I suggest that compile vendors ought to agree to get together and decide how this should be done. Leave it to the end programmer whether they want to use the feature or not, just like today we leave it to the end user whether they decide to use multiple inheritence or not. I further claim that problems with run-time type demonstrate a general problem in c++: today there is no good way to specify features in a base class that are to be implemented in each derived class. You'd think there'd be some way to use templates for such problems, but today that doesn't seem true. The best one can do today appears to be the macro class declaration/definition hack: DECLARE_CLASS(derived, base) .... }; DEFINE_CLASS(derived, base) And, like always, I claim any common, recurring theme that programmers consistently have to address via the preprocessor represents a deficiency in the language.