Newsgroups: comp.lang.c++
Path: utzoo!utgpu!craig
From: craig@gpu.utcs.utoronto.ca (Craig Hubley)
Subject: Re: asking an object for its type
Message-ID: <1991Feb21.182349.19132@gpu.utcs.utoronto.ca>
Organization: UTCS Public Access
References: <23984@netcom.COM> <1190@sheol.UUCP> <1991Feb19.000449.22255@gpu.utcs.utoronto.ca> <607@taumet.com> <65451@brunix.UUCP> <11284@pasteur.Berkeley.EDU>
Date: Thu, 21 Feb 1991 18:23:49 GMT

In article <11284@pasteur.Berkeley.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes:
>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.  

This is the programmer supporting it, not the language.  It is "possible"
but as you point out, not controllable.

>However, I would still discourage you from this type of programming.

Pun intended ?

>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.

Right on.  This why a simple typeof() won't do either.  It is possible
to build a more consistent way to tell what an object can really do,
(e.g. x.hasmember("diameter")) but this is only marginally better since
you are still requiring code to be rewritten and deal with the names,
which you supposedly already dealt with in the class header.

As you point out, this form of programming is unreliable unless others
consistently point out your convention.  Is has a far worse flaw, however,
which also applies to defining a virtual function normally:  it is not
possible for the base class programmer to anticipate everything that will
be done by the derived class programmers.  It is ridiculous to say that
the solution is to add a diameter of null value, or a virtual that does
nothing, in the base type "shape".  It is CIRCLE's problem, but as C++
works now CIRCLE can't solve it.  So shape ends up dealing with all of its
derived type's problems.  And code reusability is a myth.

A simple free function like is_legal(x.diameter) which could be partially
resolved at compile-time, and set up simple tables (like virtuals do) to
deal with remaining (runtime) ambiguities in the type.  One could apply
the same mechanism to builtins, to say things like is_legal(5/2).  With
this, my code need only depend on a very few operations, and not on 
anything's type.  The type system is in this case a great convenience
to the compiler, which can resolve my questions very efficiently.  By the
way, ANSI is already starting to discuss some form of a type tag, apparently,
since exceptions seem to require it anyway.

>But if you really want to do it, you can, so stop saying that C++ won't
>give you run-time type information.  It's trivial to add if you want it.

I disagree.  It's possible (although not trivial to maintain) IF AND ONLY IF
you are in source-code control of all of the types you derive from, which
one would hope (if we are reusing software) is not the case.  C++ needs to
deal with this.
-- 
  Craig Hubley   "...get rid of a man as soon as he thinks himself an expert."
  Craig Hubley & Associates------------------------------------Henry Ford Sr.
  craig@gpu.utcs.Utoronto.CA   UUNET!utai!utgpu!craig   craig@utorgpu.BITNET
  craig@gpu.utcs.toronto.EDU   {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig