Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!brunix!sdm
From: sdm@cs.brown.edu (Scott Meyers)
Newsgroups: comp.lang.c++
Subject: Re: asking an object for its type
Message-ID: <65451@brunix.UUCP>
Date: 19 Feb 91 17:00:44 GMT
References: <23984@netcom.COM> <1190@sheol.UUCP> <1991Feb19.000449.22255@gpu.utcs.utoronto.ca> <607@taumet.com>
Sender: news@brunix.UUCP
Reply-To: sdm@cs.brown.edu (Scott Meyers)
Organization: Brown University Department of Computer Science
Lines: 52

In article <607@taumet.com> steve@taumet.com (Stephen Clamage) writes:
| >imagine a database query:
| 
| >	"from the list of shapes, show me all the circles of diameter > 30"
| 
| All you have to do is make a virtual function diameter() for all Shapes.
| A function which expects to operate on a class of type Shape may
| reaonably expect all the functionality of Shape to be present.  It may
| not reasonably expect specific behaviors of classes derived from Shape
| to be present.

This is of course the right way to go, and most of the time it is a
workable solution, but there are times when it simply won't do.  For
example, I have a system that builds directed graphs that represent
programs, and there are various kinds of arcs in the graph:

    class Arc { ... };
    class ControlArc: public Arc { ... };
    class DataArc: public Arc { ... };
    class NPControlArc: public ControlArc { ... };
    ...

For the code that I write (i.e., the code that maintains the graph), I have
all the virtual functions defined in the appropriate places, but
applications that *use* this graph structure often need to do things that
are both specific to the application and specific to the type of the arc.
For example, an application might want to draw different kinds of arcs
differently on the screen, i.e., control arcs are red and data arcs are
black.  How can they do this if all they have is a set of Arc pointers?  In
this case, I could provide a virtual function called draw, but in general
an application might want to do something I've never heard of, so there
will be no virtual function for them to call.  That being the case, there
needs to be a way to find out the "real" type of the Arc pointer, so they
can do the appropriate thing.

I personally believe that we need language support for this kind of thing,
but it would be so prone to abuse and Bjarne is so dead-set against it that
I don't hold out much hope that it will be seriously considered by the ANSI
committee.  Instead, I think that compiler vendors will add proprietary
support for it, and there will be a market free-for-all.  I know that at
least one compiler vendor already has implemented such a facility for
getting type information at runtime.

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


-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."