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

Internet Message Format | 1992-07-30 | 4.2 KB

Xref: sparky comp.lang.c++:11841 comp.std.c++:1003
Path: sparky!uunet!dtix!darwin.sura.net!convex!constellation!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Message-ID: <[e-mail]>
Date: 30 Jul 92 17:11:27 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Lines: 86
Nntp-Posting-Host: extro.ucc.su.oz.au

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]> [e-mail] (John
>MAX Skaller) writes:
>> In article <[e-mail]> [e-mail]
>>
>>     The proposed RTTI downcast is WORSE: it return a NULL POINTER
>> if the cast fails due to type mismatch on pointers.
>>
>No. The RTTI I suggested does not return any NULL pointers. Quite simple and
>safe, the compiler does not let you program pass if there is a potential type
>error. It seems that you did not read what I wrote carefully.

    I apologise, I was indeed refering to my understanding of the
current deliberations of the ANSI/ISO committee.

    I do not recall how you proposed to constrain downcasting
so it might be detected at compile time (given the function body
to whom the parameter is passed is separately compiled).

    Such a constraint must be implemented by modifying the syntax
for parameter declarations, perhaps like so:

    f(Base[Derived1,Derived2]*);

The pointer of type Base* must be passed EVEN if it does not point
to Derived1 or Derived2, since f may sensibly use the common
base class Base to access the object.

This mechanism, incidently, leads to consideration of

    f([AnyType1,AnyType2]*);

where the types need not be related at all.

>> the proposed RTTI/downcast is any different. It may have slightly
>> better optimistaion oportunities, like all built in features.
>>
>Not just slightly. The compiler can know the specific type in many cases and
>hence can detect the type error at compile time.

    Could you give another example of how the compiler can detect
incorrect types? Certainly in the case of classes derived from a base
I do not see how passing a base could ever be wrong. And the compiler
*already* detects if a class not derived from the base is passed.

>For those types unknown to the
>compiler, the compiler can also detect the type error through RTTI.
>>
>> >Type safe downcast with RTTI will not have the above problems:
>> >
>>     WRONG. You get a system crash if you dont check for 0 pointer.
>>
>Angain, RTTI has nothing to do with null pointer. To return a null pointer for
>an RTT error is an irresponsible manner.

    Well I am sorry but I was refering to my understanding of the
current state of Bjarnes proposal, in which pointer casts to the
derived type of the wrong type yield a null pointer. (For references,
and exception is raised).

>At least, an exception should be
>raised for the error. I'm even not satisfied with the exception handling
>because you leave type error at run time! What I suggested is to detect all the
>type errors at compile time just by explicit run time type check. Sounds
>strange? I've mentioned this several times in my previous posters and examples
>are also given and I'm tired of repeating.

    I'm sorry but that sound contradictory. The compiler can
ensure a type check is done at run-time, but not statically check
the type at compile time, at least in some cases.
>
>David Shang
>
>
> --
>> ;----------------------------------------------------------------------
>>         JOHN (MAX) SKALLER,         [e-mail]
>>     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
>> ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------


--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------