TITLE: bjarne on rtti

JS = jns@ishmael.rd.wdi.disney.com (Jesse Schell)
BS = bs@research.att.com (Bjarne Stroustrup <9758-26353> 0112760), 30 Nov 95


JS:

 > I attended a lecture by Ira Pohl about the new features that are going
 > into C++ this year, and although I dozed off for parts of it, I didn't 
 > see signatures mentioned at all.

BS:

Signatures will not be part of Standard C++.

JS:

 > There were a bunch of new features that
 > let you abuse inheritance by querying inherited classes about what flavor
 > of inherited class they are,

BS:

You can of course misuse any feature, but I don't think this is a fair
description of the RTTI (Run-time type identification) facilities.

For example, a dynamic cast seems a very suitable way of recovering the
type of an object that has been transferred through and ostream and
re-assembled by the receiver:

	void user(istream& ss)
	{
		io_obj* p = get_obj(ss); // read object from stream

		if (Shape* sp = dynamic_cast<Shape*>(p)) {  // is it a Shape?
			sp->draw();	// use the Shape
			// ...
		}
		else                    // oops: non-shape in Shape file
			throw unexpected_shape();
	}

Without a dynamic_cast or some equivalent, it is hard to avoid hard-wiring
class names into this kind of program. RTTI Is (IMO) misused if it is used
where a template or a virtual function call suffices, but that is not the
case in this example.

JS:

 > and a new flavor of char that has a greater range than 0-255,

BS:

That must be the wchar_t that C++ inherited from ANSI C years ago.
Many people who deal with Japanese and Chinse considers some such
type essential. More interesting is the fact that iostreams and
strings accomodate such characters.

JS:

 > but really nothing good or useful.

BS:

Hmmm. I think I disagree. I don't really know what you consider `good or
useful,' though. Since RTTI Is not `from this year,' I don't even know
exactly which features you refer to. I consider RTTI an improvement.
The refinements of the template and exception mechanisms are significant
even if they are primarily details.

A small example: People have had problems with code bloat caused by
template instaitations:

	template<class T> class vector {
		// ...
	};

	vector<int> vi;
	vector<Shape*> vps;
	vector<dialog_box*> vdb;

usually cause three copies of the vector code to be generated. The solution
is to have a special optimized vector of pointers based on a common vector
of void*. However, having two vector classes is confusing.

Add:
	
	template<> class vector<void*> {
		  // specialized implementation for void*
	};

	template<class T> class vector<T*> : private vector<void*> {
		// specialized implementation for T*
		// relying of the common vector<void*> code
	};

and the code bloat is eliminated for the most common (pointer) case without
introducing a new name for the user to remember (or forget).

The mechanism used is commonly referred to as `partial specialization.'

Please also remember that it is not the task of a standards committee to
produce a constant stream of exciting new features. Rather, the committee
aimed at rounding off the language and specifying it precisely to create
stability.

There is now a `feature freeze' in effect.

JS:

 > The one thing I took away from the lecture was this: As of 1996, when
 > these new features are incorporated into the language, C++ will have
 > more keywords than Ada.

BS:

Keywords is a rather poor measure of complexity. For starters, you can
distinguish between keywords and reserved words depending on whether a
name may be redeclared in some context by the user or not. The simplest
way of reducing the keyword count is to have a lot of reserved words.
For example, C reserves every name in the C standard library.

In my opinion, the extensions and other resolutions have made C++ a
significantly better language (for details, see D&E). In addition, we
now also have a good standard library.