Path: utzoo!mnetor!tmsoft!torsqnt!hybrid!scifi!bywater!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: asking an object for its type
Message-ID: <70870@microsoft.UUCP>
Date: 25 Feb 91 18:41:45 GMT
References: <23984@netcom.COM> <1190@sheol.UUCP> <1991Feb19.000449.22255@gpu.utcs.utoronto.ca> <607@taumet.com> <65451@brunix.UUCP> <11284@pasteur.Berkeley.EDU>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 47

In article <11284@pasteur.Berkeley.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes:
|In article <65451@brunix.UUCP>, sdm@cs.brown.edu (Scott Meyers) writes:
||> The bottom line is that virtual functions are wonderful things and can
||> almost always be used to achieve what you want, but there are times when
||> you truly *do* need to get type information as you run.
|
|Scott then goes on to talk about how the ANSI committee is unlikely
|to give him what he wants.
|
|What do you care what the committee says?  If you must have this feature,
|write, in the baseclass
|
|	virtual const char* myType() = 0;
|
|then do
|
|const char* ControlArc::myType() { return "ControlArc";}
|
|It is already in the language if you must have it.  However, I would still
|discourage you from this type of programming.

A "trivial" solution to the run-time type problem ought to be closer
to O(1) than O(N), where N is the number of classes that need to have
some notion of run-time type.  Today, as far as I can figure out, C++
offers no way to write the run-time type stuff once in some superclass,
and then have subclasses do the right thing.  Although, using macros
you can probably get this down to a one-line macro hack per derived
class.

Thus, I'd say C++ enables, but does not support, run-time type approaches.

|Why?  Because people will add new types of Arcs and you won't deal with
|them properly.  You're dealing with objects based on an exact match of
|some type string instead of based on some relevant attribute that a
|virtual function could return.  You're wiring in a list of classes you
|can handle, requiring more code rewriting as classes are added.

I agree that relying on exact type testing is bad.  But I don't agree that
relying on inexact type testing is bad.  Rather, I find it necessary in
a wide variety of situations.

Also, without language support, each library will implement its own 
notion of run-time type, generally precluding mixed-use of those 
libraries.

I'd like to see consideration of some standard features in support of
run-time type.