C++: "Type Checking"

[Web Developer]

Hi,

I come across the term "type checking" very often in my readings on C++, and
have never heard it in Java. Besides the simplistic answer that it checks
the "type", what more does it mean?


WD

 

[John Harrison]

Hi,

I come across the term "type checking" very often in my readings on C++, and
have never heard it in Java. Besides the simplistic answer that it checks
the "type", what more does it mean?


WD

I think its a question of timing. All languages check types, you aren't
allowed to multiply two strings in any language (AFAIK). But some languages
delay type checking until the program runs. C++ does most of its type
checking at compile type. This results in faster code, smaller data and
quicker detection of type errors, but it also means a more complex language.

We say C++ is a strongly typed language. In general I would say strong
typing is a good thing but there are occasions where you want to relax it
and check types at run time. That's where virtual functions and RTTI come
in.

john

 

[Alf P. Steinbach]

Java is also a strongly typed language and checks for compatible types for
method arguments and return values at compile time.

Nope. Consider classes A, B and C in separate files, where A uses B uses
C, and A is the "main" program. Compile all. Change C to be incompatible
with B. Compile class A using Sun's compiler: no errors reported. Run.
Runtime error.

That could not happen in C++.

C++ has _global_ static type checking; Java has runtime type checking.

 

[Alf P. Steinbach]

The Java language has stronger static type checking than C++. e.g.
implicit conversions from double to int, etc. don't exist. C++ however
has better idioms for static type checking, thanks to using generics
rather than an Object base-of-all class. Java encourages use of the
evil instanceof operator.

I think you're talking about the link time safety that C++ has thanks
to name mangling. But C++ will just crash if you replace a DLL with
another one with incompatible types, so I don't get your point.

DLLs are not part of C++.

Java will detect the problem if you recompile

Nope. Java will only detect the problem if you recompile class B.
You have an executable system without recompiling class B (and this is
not theoretical, it has been a major problem in some large Java projects).

just as happens with C++.

Nope. With C++ you have global type-checking. You cannot obtain an
executable with static type inconsistencies.

 

[ghl]

Nope. Consider classes A, B and C in separate files, where A uses B uses
C, and A is the "main" program. Compile all. Change C to be incompatible
with B. Compile class A using Sun's compiler: no errors reported. Run.
Runtime error.

Wrong. Been there. Tried that.
Created classes as above, all returning String type reference variable.
Changed return type of C to int. Message on recompiling A gives:
..\C.java:3: incompatible types
found : java.lang.String
required: int
public int info = "I'm c";
^
..\C.java:13: incompatible types
found : int
required: java.lang.String
return info;
^
2 errors

 

[ghl]

"Change" means: change the source code of class C, compile class C.

Then compile class A, or not (it makes no difference), and run:


Exception in thread "main" java.lang.NoSuchMethodError: C.result()Ljava/lang/String;
at B.result(B.java:5)
at A.main(A.java:5)


Got it?

Ah, I get what you're driving at. Yes, you get that. Does the same thing
happen in C++ with the linker detecting the change?
The Java error at runtime is detected because there is no linker and the
type checking can only occur when class C is actually loaded and checked.
I get your point.

 

[Alf P. Steinbach]

Ah, I get what you're driving at. Yes, you get that. Does the same thing
happen in C++ with the linker detecting the change?

In practice the linker detects the change, yes.

In theory there need not be a linker in a C++ implementation, but the
_language_ (standard) guarantees global static type-checking whatever
execution system is actually used.

There's no runtime error because you don't get an executable.