Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: asking an object for its type
Message-ID: <71037@microsoft.UUCP>
Date: 4 Mar 91 20:57:39 GMT
References: <1991Feb20.232710.7843@ithaca.uucp> <1485@acf5.NYU.EDU>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 107

In article <1485@acf5.NYU.EDU> sabbagh@acf5.NYU.EDU (sabbagh) writes:
|garry@ithaca.uucp (Garry Wiegand) writes:
|
|>This "isKindOf" argument keeps coming up. Perhaps the problem should
|>be attacked the other way: what would it take to allow an application 
|>to add a virtual function to an existing class (for which the
|>application programmer doesn't have source)?
|
|Unfortunately, much of this discussion has been abstract, in the sense
|that "C++ should provide the ability to check a class type at run-time".
|My basic counter-argument is: why?
|
|If the application calls for run-time type checking, then it can be built
|into the system using C++.  Its not particularly easy, but it is not 
|wasted effort, SINCE THE DESIGN CALLS FOR THIS ABILITY.  This would come
|up in database applications, graphics, etc. where the end-user needs 
|to select objects at run-time.

To restate your question:

Why should C++ actively support runtime type testing when the issue
keeps coming up again and again, and when with great difficulty individual 
applications can create it for themselves.

Answer:

C++ should actively support runtime type testing because the issue keeps
coming up again and again and it takes great difficulty for individual 
applications to create it for themselves.  

Even if individual applications do create run-time type systems for 
themselves, such systems are unique to a particular application or 
set of libraries and thus prevent code from being reused.

Conversely, if C++ offered the required template support to make implementing 
run-time type implementations easy, then C++ could be said to "support" run-time
type testing even if such run-time type testing weren't built into the 
language.  It could be handles by libraries instead.  You'd still need
a standard to specify how those libraries should work.

"C" *could* be used for OOP -- but it would require awkward, ugly,
error prone hacks every where in order to do "virtual" functions.
Thus, we say C does not *support* OOP.  Likewise, today we say C++
*supports* OOP, but it does not *support* run-time type checking.

|Finally, general observations.  C++ was originally designed to augment
|the C with object-oriented capabilities and other facilities to make
|programming-in-the-large easier.  C was intended as a systems language;
|C++ still hold true to this.  

I disagree.   I see C++ as a general-purpose compiled OOPL with wide
applicability in that arena.  I believe many more people are using 
C++ for creating applications than are using C++ for systems.  This
was also true for C.  The fact that the original authors were involved
in systems design meant that they appreciated a language that can be
compiled to excellent quality code.  But these same capabilities are
required for competitive applications today.

|If you are looking for a fully interpreted
|environment in which everything is an object, use Smalltalk.  If you
|want to build applications on a wide variety of hardware and software
|platforms and want better productivity than offered by C, use C++. You
|can implement Smalltalk (or CLOS, or whatever) in C++, but then you
|would be implementing an intrepreter, not an easy task in any language.

The implication being that run-time type testing requires an interpreter-
like approach, or that adding run-time type testing turns C++ into 
a Smalltalk or a CLOS.  I disagree.  What is needed is better compiler
support.  My preferred solution to this problem is to improve the capabilities
of templates, such that derived classes can automatically expand some
methods specified in the base class via the sole action of being derived.
Failing such improvements to templates, I'd like to see agreement among
vendors about the "right" way to support run-time type checking -- so that
N dialects don't spring up -- and they will, because the issue of run-time
type testing keeps coming up over and over again.  This is like multiple
inheritence.  Good implementations don't make you pay extra cost for 
multiple inheritence if you don't use it.  So if you don't like it, 
don't use it.  But if C++ didn't support multiple inheritance, then
vendors would come up with multiple, independent, incompatible versions
of it. Likewise run-time type testing.  It can be implemented such
that people who don't use it, don't pay for it.  But if it isn't specified
in that language, multiple incompatible dialects will spring up.

Here's a simple example of where better template support is needed.
This is really an example of run-time type information -- but few people
would consider it "controversial."

Let's say in a base class "Object" you require all subclass be able 
to tell you the size of their objects.  You need to know their size 
for serialization, deserialization, whatever.  Why can't you
just specify such a virtual method in a base class, and have it 
automatically expanded via templates in all subclasses???  You'd
think templates would provide such a capability, but they don't:

class Object
{
....
public:
	// choose your favorite syntax for the below:
	template virtual int size() { return sizeof(this_class); }
};

-- where the intent is that size() is a templated member function 
that is automatically expanded on any derivation from Object.
Surprisingly, there doesn't seem to be any reasonable way of doing this
via today's definition of templates.  Which seems like a hole in the
template definition to me!