From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Mon, 27 Jul 92 17:02:55 GMT

> In article <1992Jul24.143359.3602@advtech.uswest.com> glw@io.uswest.com  
(Glenn Williams) writes:
> >
> >Ok, let's have an example of a properly designed system. 

In article <1992Jul24.192207.15267@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU  
(John MAX Skaller) replies:
> 
> 	But that wont PROVE anything. You have to give me
> an example of a system that uses downcasting and then I'll
> show how to write it without downcasting.
> 
Your example "mate" is already a good example! And you did not provide a good  
solution without downcasting. Using virtual function "Species()" can certainly  
eliminates the necessity of downcast, but it introduces severe problems that a  
safe downcast would never have.

First of all, you must remember to override the virtual function in each  
derived class, and give the proper return value. If a forget to override, or if  
a give a name that happened to be the same name already exists, you make a  
trouble. The compiler has no way to help you to establish a proper name  
distribution.

Secondly, you must remember to run time check the character strings returned by  
the virtual function. If you forget, you may put a cat and a rat together! The  
compiler has no way to help you essure the correct match!

Lastly, you leave much checking work that should be done at compile time to be  
done at run time. On one head, you let down the run time performance. On the  
other head, you leave errors that should be detected at compile time to the run  
time.

Type safe downcast with RTTI will not have the above problems:

Firstly, the compiler will generate a proper type identifier for each type. The  
detailed type information can be stored in files generated by the compiler, and  
the library can provide a set of suitable functions to access these detail type  
information through the type id. Howerver, for the purpose of downcast, only  
the simple type id is needed. The programmer is never bothered by overriding a  
virtual function that returns a character string or an interger that serves as  
the type id. No error will be concerned about a mis-produced type id at run  
time.

Secondly, If you forget to run time type check a type id for a type that is  
unknown to the compiler, the compiler will tell you there is a potential error  
in your program. Thus, if you pass your program, no error will be concerned  
about a mis-match, and the proper downcast will be automaticaly performed (the  
programmer is not required to write the explicit downcast) at run time.

Lastly, much check work can be done at compile time. When the type is known to  
the compiler, the compiler will detect all the mismatch before the program is  
put into running. For example: the compiler will not let "cat->mate(rat)" pass.  
This is an evident error, why should we leave it to run time?

> 	Please restrict examples to domestic systems, since
> I already agree all bets are off for foreign systems and
> also for introspective ones like, say, debuggers, OODBMS,
> etc.
> 
Your "mate" example is definitely a domestic system.

> 	Sure. But you have to tell me what problem you want to solve,
> else I'll just give you a copy of my, um lets see, matrix clas,
> or perhaps my network emulator, or perhaps my chemical plant
> Quantative Risk Analysis Program.
>
I want a version of "mate" that does not use downcast and works as well as (I  
even do not require the better!) the TYPE SAFE downcast as I suggested (do not  
confuse my argument with unsafe downcast, I'm stronly against unsafe downcast).   

David Shang

Newsgroups: comp.lang.c++