Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!rutgers!rochester!kodak!islsun!cok
From: cok@islsun.Kodak.COM (David Cok)
Newsgroups: comp.lang.c++
Subject: Re: typesafe downward casting
Message-ID: <1991Apr2.161809.16952@kodak.kodak.com>
Date: 2 Apr 91 16:18:09 GMT
References: <1991Mar30.161252.26129@kodak.kodak.com> <18.UUL1.3#8618@softrue.UUCP>
Sender: cok@Kodak.COM
Organization: Eastman Kodak Co., Rochester, NY
Lines: 63

In article <18.UUL1.3#8618@softrue.UUCP> kearns@softrue.UUCP (Steven Kearns) writes:
>> From: cok@islsun.Kodak.COM (David Cok)
>> Subject: Re: typesafe downward casting
>> ....
>>And if you can prove that global variables are used correctly, and goto's,and
>> case statements or types, you should not feel guilty???  Some constructs are
>> error-inviting -- cast is one of them -- and are best avoided.  If you need
>> to use them, you have to be very careful, but if a program has a lot of them
>> bugs are likely.  
>
>Yes, if you can prove that your goto is correct, you should feel very
>satisfied.  The only reason to avoid these statements, as Djikstra
>would say, is because they complicate the proof of correctness.  It
>seems to me that knowing that a Base* actually points to a Derived*
>is about as trivial as knowing that a number is non-negative.  If you
>cannot handle this, I suggest taking up a different profession ;-}.
>
No, you should feel satisfied only if it is correct and is a good design.  One
measure of goodness of design is the speed with which a person unfamiliar
with the code can justify its correctness -- and gotos generally, but not
always, make that harder.  Global variables require being aware of a lot more
information than local variables -- and hence complicate (slow down) verifying
correctness.  I would maintain that uncheckable casts fall into the same
category, and that a good program generally has few casts and a good 
programming language allows most programs to be written without casts.
Knowing that a Base* points to a Derived* is about as trivial as knowing
that a number is non-negative: both are undecidable in general at compile-time.
At least C++ provides a nice little run-time test to see if a number is 
non-negative; it does not provide that for casting (except in a messy way -- 
see below).

>> >If we added stuff to C++ to take care of this "problem", then we would
>> >also have to add new types so that people do not call sqrt(x) when
>> >x is a negative number, or so they do not call a/b when b is 0.  
>> >
>> No, you don't have to. Every language is a trade-off between what is checked
>> at compile-time, what is checked at run-time, and what is left to cause core
>> dumps, often at places far from the original problem.  People differ as to
>> what should be in which category -- ....
>> I think that a type-safe downcast is a legitimate thing to consider
>> supporting at run-time.
>
>That is the point: there is no compelling reason to include it in the
>language except for your opinion.  Why make type-safe downcasts but
>non-type-safe division?  Fortunately, C++ gives you enough tools so
>that you can ensure type-safe downcasting if you want, while I can
>avoid them if I want.  
>
But there is no compelling reason to leave it out except for your opinion :-)
I'll take "opinion" here to be a position on language design based on some
rational considerations -- on which reasonable people can disagree and can
discuss without resorting to ad hominem arguments.

Current C++ can supply type-safe downcasting only with (a) source code
access to base classes, including libraries, and (b) building into base
classes knowledge of each derived class.  I maintain that each of those 
individually is too big a price to pay for what is a straightforward
language feature.


David R. Cok
Eastman Kodak Company -- Imaging Science Lab
cok@Kodak.COM