Re: dynamic type checking - a pauline conversion?

From: Jeff Brooks (jeff_brooks_at_nospam.com)
Date: 03/19/04 

Date: Fri, 19 Mar 2004 10:43:24 GMT

Hello everyone! This is a really interesting debate!

A few points keep coming up as arguments which i don't feel are valid.
Since its late i won't mention them all. One of the points i disagree
with is people seem to believe that because C++ is statically typed that
it is somehow more reliable then dynamically typed languages.

I wrote a small program in C++ to demonstrate my point (I used gcc 2.95.2).

--- a.c++ ---
#include <iostream.h>

class A
{
public:
   int a;
   int b;

   void print();
};

class B
{
public:
   int b;
   int a;

   void print();
   void dumbTypeCall();
};

void A::print()
{
   cout << "a = " << a << endl;
   cout << "b = " << b << endl;
}

void B::print()
{
   cout << "a = " << a << endl;
   cout << "b = " << b << endl;
}

void B::dumbTypeCall()
{
   cout << "Should this be possible?" << endl;
}

int main()
{
   A *a = new A();
   B *b = (B*)a;

   b->a = 3;
   b->b = 1;

   a->print();
   b->print();
   b->dumbTypeCall();

   return 0;
} 

---
The output for this code (yes it successfully compiled! O.o) is:
--- snip ---
a = 1
b = 3
a = 3
b = 1
Should this be possible?
---
I compiled this with all warnings on and it didn't give me any. Does 
anyone here believe 'b' (class B) should be able to reference to the 
same instance as 'a' (class A)? How is this safe?
When i call print on 'a' it shows a=1, b=3.
When i call print on 'b' it shows a=3, b=1.
So the print that is dispatched doesn't depend on the object i'm 
refering to, it depends on the type of reference to the object. It 
wouldn't have mattered if i made the methods virtual because they don't 
share the same super class. This doesn't stop C++ from allowing me to 
assign 'a' to 'b'!
I then call dumbTypeCall() on 'b' (which points to an instance of class 
A). This works without any problem even though class A doesn't have a 
method called dumbTypeCall.
A lot of developers seem to think that because C++ verifies that the 
reference type has the appropriate methods at compile time this makes 
C++ reliable. This would be true if the reference type actually matched 
the type of the object being pointed to in all cases but C++ makes no 
such guarantee.
In Smalltalk the reference doesn't have a type but the instance does 
have a type. All method invocation is based on the type of the instance 
which means the correct method is always called (this can be guaranteed 
at runtime). In Smalltalk calling a method that doesn't exist causes an 
exception to be thrown at runtime.
Both Smalltalk, and C++ can not guarantee type correctness at compile 
time. Smalltalk handles runtime errors better then C++ does (most of
the time C++ doesn't fail even though the code is broken).
Jeff Brooks

Relevant Pages

  • STL and the SDK
    ... I tried to compile some STL code and I got ... TestOb(int iMemInit):m_iMem ... see reference to function template instantiation ...
    (microsoft.public.vc.language)
  • Re: Difference between variable declarations...
    ... >> The former is a reference to an integer, ... The following should compile: ... int main ...
    (comp.lang.cpp)
  • Returning by value, returning by reference
    ... When I compile and run the following on my system: ... static int hello = 78; ... int ReturnValue ... You can bind a temporary returned from a function to a reference. ...
    (comp.lang.cpp)
  • Re: GCC difference in size of long int on Suse SLES9 / Suse Professional 10.0
    ... The kernel uses printf() with 'long int', ... I can't compile 'on-the-fly'. ... clashing with the hardware and any libs that you interact with. ... platform types build up their own int types. ...
    (comp.os.linux.development.apps)
  • Re: Seeing Access 2003 table in Access 2007
    ... The reason you're not able to compile is likely because code is running. ... VBA code in your database will not be disabled from the get-go. ... I had a second missing reference which I ... Compile {ProjectName}, where is the name of your VBA ...
    (microsoft.public.access.gettingstarted)