Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!nih-csl!sparkler.dcrt.nih.gov!kgorlen
From: kgorlen@sparkler.dcrt.nih.gov (Keith Gorlen)
Newsgroups: comp.lang.c++
Subject: Re: libraries, compilers, class info, exceptions
Message-ID: <534@nih-csl.nih.gov>
Date: 25 Sep 90 22:01:01 GMT
References: <995@halley.UUCP> <CLINE.90Sep25002931@cheetah.ece.clarkson.edu>
Sender: news@nih-csl.nih.gov
Reply-To: kgorlen@sparkler.dcrt.nih.gov (Keith Gorlen)
Lines: 79

In article <CLINE.90Sep25002931@cheetah.ece.clarkson.edu>,
cline@cheetah.ece.clarkson.edu (Marshall Cline) writes:
|>Runtime (weak) typing is wonderful if you want a toy language that will
|>solve toy problems.  Strong typing is nearly essential for programming in
|>the large.  Smalltalk provides runtime typing but does NOT provide any
|>compile time typing.  C++ is exactly the opposite, which is the real tragedy
|>of translating Smalltalk-like libraries into C++.  Ie: forget the speed hit.
|>Forget the 2x to 3x more new/delete calls caused by the Smalltalk model.
|>Forget the 2x more pointer dereferences, and just think about discarding the
|>only ONLY **ONLY** type checking the language *gives* you.  The Smalltalk
|>library was designed for Smalltalk, but not for C++.
|>
|>Not to sound like I'm double minded or anything, but Keith Gorlen's NIHCL
|>does a wonderful job of providing persistent objects.  Ideally persistence
|>should be buried in the language so as to avoid the temptation to check the
|>type of an object at runtime for other purposes as well (it may sound
|>trivial, but: you only need to check the type of a referenced object when
|>you don't know the type, and that implies you're relying on weak typing).  I
|>wish C++ proper gave us persistence; that way no one would have to pay the
|>horrible prices imposed by Smalltalk-like C++ libraries.
|>
|>Pointer casting is the goto of OOP.
|>In structured programming, everything revolves around the control flow.
|>Goto's can mess up the control flow, which messes up `everything'.
|>
|>In OOPLs, everything is in the `type' of the objects.
|>Pointer casts can mess up the type, which messes up `everything'.
|>
|>I think you'll find that the template mechanism will give you the kind of
|>flexibility to conveniently support strong typing.  You'll never (well...
|>*almost* never) have to do a pointer cast.
|>
|>Marshall Cline
                                                                 
While I'm sympathetic with this statement, I don't think I'd characterize the
use of Smalltalk-like libraries with C++ as a "tragedy".  As Marshall admits,
there are times when you have to do a pointer cast.  For example, if
you're using
a polymorphic container, you will at times need to do a downward cast to the 
derived type of an object obtained from the container.  If you *have* to
do such a
cast, it's better to have a mechanism for checking that the cast is safe rather
than just doing it without protection.  I think this issue is more
likely to arise
for the designer of a highy general, reuseable, library class who can
make fewer
assumptions about what is safe than for an applications-level programmer.

One problem with the Smalltalk approach is that since only general, polymorhic
containers are provided, they are used in places where a type-specific
container would suffice, thus possibly sacrificing type safety and efficiency.
An improvement would be to provide type-parameterized container classes that
could handle both polymorhic and type-specific situations, as we discuss
briefly
in Section 14.3 of our book.

A related problem with using the Smalltalk approach in C++ is the tendency to
define a base class with a set of virtual member functions that is the union of
all the virtual functions implemented by all its derived classes.  This is done
in an attempt to eliminate the need for downward casts.  The problem is that
when a derived class can't sensibly implement one of these virtual
functions, it
implements it to cause a run-time error, which amounts to a subtle way of
bypassing C++'s static type checking *without* an explicit downward cast.
Using multiple inheritance so that derived classes can be more selective about
which inherited virtual functions they are expected to implement may offer some
help with this problem.

There are some problems with the Smalltalk approach, but I don't think
it should
be trashed because of them.  Rather, I think it's an interesting starting point
for making use of new or future C++ features such as multiple inheritance and
parameterized types.


	Keith Gorlen			phone: (301) 496-1111
	Building 12A, Room 2033		uucp: uunet!nih-csl!kgorlen
	National Institutes of Health	Internet: kgorlen@alw.nih.gov
	Bethesda, MD 20892