🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #48

Re: run-time type checking (was: Re: Covariant Types in Derived Classes)

#48
From: David (Lujun) Shang
Date: Fri, 31 Jul 1992 23:49
101 lines
4022 bytes
In article <1992Jul30.171127.18238@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU  
(John MAX Skaller) writes:
> 	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).
>
Very simple: using RTTC to keep a type safe downcast. If you want to cast an  
animal to a cat, check whether the animal is actually a cat. If you want to  
cast an argument of some unknown type T1 to an argument of some unknown type  
T2, check whether T1 is actually T2. If you do not check, the compiler tells  
you that your program has a potential error.
 
> 	Such a constraint must be implemented by modifying the syntax
> for parameter declarations, perhaps like so:
> 
> 	f(Base[Derived1,Derived2]*);
>
No, not help, just for the reason you give: given the function body to whom the  
parameter is passed is separately compiled.

> 	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.
>
Your "mate" example is the best one, I don't think it is necessary to make a  
new one.

    Animal::mate (thiscalss &peer);
    // you needn't check whether peer is the same type as this object
    // since the interface ensures that.

    Cat c1,c2;
    Dog d1,d2;
    Crockdile k1, k2;
    Lizard z1, z2;
    Mammal *m1, *m2;
    Reptile *r1, *r2;
    Animal *a1, *a2;

    c1.mate(c2);   // okay.
    c1.mate(d1);   // error detected by compiler

    m1 = &d1;
    a1 = &d2;
    m1->mate(*a2);  // okay (through type inference)

    m1 = &c1;
    m2 = &d2;
    m1->mate(*m2);  // error detected by compiler (through type inference)

    a1->mate(*a2);  // error detected by compiler (two unitialized types)

    m1 = new Mammal;
    m2 = new Mammal;
    m1->mate(*m2);  // okay. Note that if Mammal can be instantiated
                    // by new, "mate" has to be defined in class Mammal,
                    // so that "mate" at the Mammal level is meaningful.
                    // If you cannot write "mate" at Mammal level, Mammal
                    // must be remain abstract, and this case will never
                    // happen!

    void foo (Animal *a1, Animal *a2)
    { 
      a1->mate(*a2);  // error detected by the compiler
    }

    void foo (Animal *a, Reptile *r)
    { 
      if (a#==r#) a->mate(*r);  // okay (I use a# to express typeof(*a))
    }

    void foo (Animal *a)
    { Dog d;
      Cat c;
      if (a#==Dog)
      {  a->mate(d);      // okay
         *a = d;          // okay
      }
      else
         *a = c;         // error
    }

    <Animal AnimalType> void foo (AnimalType *a1, AnimalType *a2)
    { 
      a1->mate(*a2);  // okay
    }


> >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 ...
>
> 	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.

I hope the above example can convince you that the resulting program will be  
type-error free at run time.

David Shang
Technical Details
Message-ID: <1992Jul31.234928.1313@cadsun.corp.mot.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!ftpbox!motsrd!news
References: <1992Jul30.171127.18238@ucc.su.OZ.AU>

Show Full Headers
Complete Article Headers
Newsgroups: comp.std.c++,comp.lang.c++
Path: arc1-ca.pugleaf.net!sparky!uunet!ftpbox!motsrd!news
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Message-ID: <1992Jul31.234928.1313@cadsun.corp.mot.com>
Sender: news@cadsun.corp.mot.com
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
References: <1992Jul30.171127.18238@ucc.su.OZ.AU>
Date: Fri, 31 Jul 92 23:49:28 GMT
Lines: 102