From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: Language extensions for run-time type identification
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Wed, 29 Jul 92 19:20:54 GMT

In article <BryFLI.Hz2@world.std.com> wmm@world.std.com (William M Miller)  
writes:
> 
> Consider this: dynamic typing is only required when you've "lost" the
> exact type of the object to which an expression refers.  In all other
> cases, the static type of the expression is sufficient, and the
> compiler can just provide a direct reference to the typeinfo if the
> program requests type information.
>
Definitely true.
 
> There are only two ways to "lose" the exact type in C++ (apart from
> explicit casting to an unrelated type, for instance): conversion of a
> pointer/reference to a derived class into a pointer/reference to a
> base class, and conversion to void*.  
>
Also True, but only within a domestic environment.

> Doing something about the latter
> is either very expensive or requires breaking compatibility with C
> void* pointers (tagged pointers),
>
True, if you do not relate the void* to the tagged pointer. Only those  
polymorphic pointers need to be tagged. void* is not a polymorphic pointer. If  
we want an equivalent polymorphic pointer, we can introduce a new one:  
anytype*, where anytype is supposed to be the root of class hierarchy. You get  
penalty only when you use it.

> so realistically we are talking
> about a requirement for RTTI that *only* has to deal with the results
> of derived-to-base conversions.
>
Not exactly. It is true within a domestic environment.
 
> The question, then, is under what circumstances do such conversions
> occur?  The premise of the current proposal is that you don't *do*
> such conversions unless you have provided for polymorphic behavior,
> i.e., virtual functions. Inheritance for factoring and sharing of
> representation and code is fine, but in such applications you
> typically don't rely on derived-to-base conversions.
>
Not entirely true even for a domestic system: 

I often have a class hierachy in which the base methods manipulate only on the  
part of the base data and no virtualization is required. All the specific  
operations in the derived classes will be performed from the specific  
interfaces. But I still need a general interface that manipultes all of the  
object at the base level. Virtual functions can help a lot in reducing the  
neccessity of downcast and hence the need of RTTI. But virtual function does  
not always help. Sometimes the specific interfaces and requirements can vary  
greatly in derived classes, it is impossible to exract a common interface as a  
virtual interface. In this case, I have to use RTTI rather than the virtual  
function.

> The challenge, then, for those who view RTTI-via-vtable as
> insufficient is to provide *concrete* counterexamples to this
> assumption: applications where derived-to-base casting does occur
> without the need for virtual functions and for which RTTI would
> nevertheless be useful.  Are there such applications?
> 
Yes. 

I can maintain a group of passive objects without intrinsic behavioral  
characteristics, needless to say any virtual functions. What I am concerned is  
only the internal data structure. These objects are usually used to carry the  
information and to be transfered between different environments. I need RTTI to  
represent or transform these objects correctly. For example, to transform an  
integer in an object from Intel 8086 form to network form. Although a simple  
type id is usually insufficient for this case, but it provides a key to access  
the detail type information in some type library generated by the compiler (I  
just hate to see the game of waste: inventing one precompiler after another).

My multitasking system can also have an interface that take an object as input  
from other task. Such object is not necessarily virtualized. Such type check is  
usaually performed at run time. Without RTTI, my task may corrupt due to a  
wrong input type. Without language supported RTTI, I have to provide my own  
RTTI to solve this problem. If the system is general purposed and must be  
integrated with the language environment, again, I have to write a precompiler  
to create my own language (example: IDL for remote procedure call)!
  
And I'm sure many OO database and OS people can tell more.

Since OO technique is aimed mainly to developing large, complex and  
coorperative systems, C++, as general purposed OO language, should at least  
cover some main application areas.

David Shang
Newsgroups: comp.lang.c++