NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/lang/cplus/11677

Internet Message Format | 1992-07-28 | 2.5 KB

Xref: sparky comp.lang.c++:11677 comp.std.c++:976
Newsgroups: comp.lang.c++,comp.std.c++
Path: sparky!uunet!world!wmm
From: [e-mail] (William M Miller)
Subject: Re: Language extensions for run-time type identification
Message-ID: <[e-mail]>
Organization: Software Emancipation Technology, Inc.
References: <[e-mail]!mole-end> <[e-mail]>
Date: Sat, 25 Jul 1992 17:08:05 GMT
Lines: 38

I'd like to make a short comment about the rationale for providing
RTTI only for classes with virtual functions -- even though I
suggested what I considered to be a practical way of providing RTTI
for classes without virtual functions (not tagged pointers, BTW), I
can understand the reasoning for restricting RTTI.  It's not just
convenience in piggybacking onto existing technology, although that is
an attractive aspect of the current proposal.  The real question is
when RTTI is likely to be used.

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.

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*.  Doing something about the latter
is either very expensive or requires breaking compatibility with C
void* pointers (tagged pointers), so realistically we are talking
about a requirement for RTTI that *only* has to deal with the results
of derived-to-base conversions.

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.

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?

-- William M. Miller, [e-mail]