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

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

Xref: sparky comp.lang.c++:11706 comp.std.c++:983
Newsgroups: comp.lang.c++,comp.std.c++
Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]>
Date: Tue, 28 Jul 1992 21:45:28 GMT
Lines: 69

In article <[e-mail]> [e-mail] writes:
>> In article <[e-mail]> [e-mail]
>(Glenn Williams) writes:
>> >
>> >Ok, let's have an example of a properly designed system.
>
>In article <[e-mail]> [e-mail]
>(John MAX Skaller) replies:
>>
>>     But that wont PROVE anything. You have to give me
>> an example of a system that uses downcasting and then I'll
>> show how to write it without downcasting.
>>
>Your example "mate" is already a good example! And you did not provide a good
>solution without downcasting. Using virtual function "Species()" can certainly
>eliminates the necessity of downcast, but it introduces severe problems that a
>safe downcast would never have.
>
>First of all, you must remember to override the virtual function in each
>derived class, and give the proper return value. If a forget to override, or if
>a give a name that happened to be the same name already exists, you make a
>trouble. The compiler has no way to help you to establish a proper name
>distribution.

    The first is WRONG. Havent you ever head of PURE VIRTUAL FUNCTIONS????

    The second is a CONSEQUENCE of being able to
    chose the species name for each class. Thats
    DESIRABLE if you want to support multiple
    implementation of the same class.

>
>Secondly, you must remember to run time check the character strings returned by
>the virtual function. If you forget, you may put a cat and a rat together! The
>compiler has no way to help you essure the correct match!

    The proposed RTTI downcast is WORSE: it return a NULL POINTER
if the cast fails due to type mismatch on pointers.

>
>Lastly, you leave much checking work that should be done at compile time to be
>done at run time.

    In this case maybe thats true. I dont see how
the proposed RTTI/downcast is any different. It may have slightly
better optimistaion oportunities, like all built in features.


>On one head, you let down the run time performance. On the
>other head, you leave errors that should be detected at compile time to the run
>time.
>
>Type safe downcast with RTTI will not have the above problems:
>
>Firstly, the compiler will generate a proper type identifier for each type. The
>detailed type information can be stored in files generated by the compiler, and
>the library can provide a set of suitable functions to access these detail type
>information through the type id. Howerver, for the purpose of downcast, only
>the simple type id is needed. The programmer is never bothered by overriding a
>virtual function that returns a character string or an interger that serves as
>the type id. No error will be concerned about a mis-produced type id at run
>time.

    WRONG. You get a system crash if you dont check for 0 pointer.
--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------