Types

Antonio Cisternino

Programmazione Avanzata

Types

Computer hardware is capable of interpreting bits in memory in several different ways

A type limit the set of operations that may be performed on a value belonging to it

The hardware usually doesn’t enforce the notion of type, though it provides operations for numbers and pointers

Programming languages tend to associate types to value to enforce error-checking

Type system

A type system consists of:A mechanism for defining types and

associating them with certain language constructs

A set of rules for: type equivalence: two values are the same type compatibility: a value of a given type can be

used in a given context type inference: type of an expression given the

type of its constituents

Type checking Type checking is the process of ensuring that a

program obeys the language’s type compatibility rules

A language is strongly typed if it prohibits, in a way that the language implementation can enforce, the application of any operation to any object that is not intended to support that operation

A language is statically typed if it is strongly typed and type checking can be performed at compile time

Programming Languages and type checking Assembly C Pascal C++ Java Lisp Prolog ML

No type checking

Static type checkingNot entirely strongly typed (union, interoperability of pointers and arrays)

Static type checkingNot entirely strongly typed (untagged variant records)

Static type checkingNot entirely strongly typed (as C)Dynamic type checking (virtual methods)

Static type checkingDynamic type checking (virtual methods, upcasting) Strongly typedDynamic type checking Strongly typedDynamic type checking

Strongly typedStatic type checking Strongly typed

Different views for types

Denotational: types are set of values (domains) Application: semantics

Constructive: Built-in types Composite types (application of type constructors)

Abstraction-based: Type is an interface consisting of a set of operations

Language types

Boolean Int, long, float, double (signed/unsigned) Characters (1 byte, 2 bytes) Enumeration Subrange (n1..n2) Composite types:

Struct Union Arrays Pointers List

Type Conversions and Casts

Consider the following definition:int add(int i, int j);

int add2(int i, double j);

And the following calls:add(2, 3); // Exact

add(2, (int)3.0); // Explicit cast

add2(2, 3); // Implicit cast

Memory Layout

Typically hardware-types on 32 bits architectures require from 1 to 8 bytes

Composite types are represented by chaining constituent values together

For performance reasons often compilers employ padding to align fields to 4 bytes addresses

Memory layout example

struct element {

char name[2];

int atomic_number;

double atomic_weight;

char metallic;

};

4 bytes/32 bits

name

atomic_number

atomic_weight

metallic

Optimizing Memory Layout

C requires that fields of struct should be displaced in the same order of the declaration (essential for working with pointers!)

Not all languages behaves like this: for instance ML doesn’t specify any order

If the compiler is free of reorganizing fields holes can be minimized (in the example by packing metallic with name saving 4 bytes)

4 bytes/32 bits

name

atomic_number

atomic_weight

metallic

Union

Union types allow sharing the same memory area among different types

The size of the value is the maximum of the constituents

4 bytes/32 bits

numberunion u { struct element e; int number;};

Abstract Data Types

According to the abstraction-based view of types a type is an interface

An ADT defines a set of values and the operations allowed on it

In their evolution programming languages have included mechanisms to define ADT

Definition of an ADT requires the ability of incapsulating values and operations

Example: a C list

struct node { int val; struct list *next;};struct node* next(struct node* l) { return l->next; }struct node* initNode(struct node* l, int v) { l->val = v; l->next = NULL; return l;}void append(struct node* l, int v) { struct node p = l; while (p->next) p = p->next; p->next = initNode((struct node)malloc(sizeof(struct node)), v);}

ADT, modules and classes

C doesn’t provide any mechanism to hide the structure of data types

A program can access the next pointer without using the next function.

The notion of module has been introduced to define data types and restrict the access to their definition

An evolution of module is the class: values and operations are tied together (with the addition of inheritance)

Class type

Class is a type constructor like struct and array A class combines other types like structs Class definition contains also methods which are

the operations allowed on the data The inheritance relation is introduced Two special operations provide control over

initialization and finalization of objects

The Node Type in Java

class Node { int val; Node m_next; Node(int v) { val = v; } Node next() { return m_next; } void append(int v) { Node n = this; while (n.m_next != null) n = n.m_next; n.m_next = new Node(v); }}

Inheritance

If the class A inherits from class B (A<:B) when an object of class B is expected an object of class A can be used instead

Inheritance expresses the idea of adding features to an existing type (both methods and attributes)

Inheritance can be single or multiple

Example

class A { int i; int j; int foo() { return i + j; }}class B : A { int k; int foo() { return k + super.foo(); }}

Questions

Consider the following:A a = new A();

A b = new B();

Console.WriteLine(a.foo());

Console.WriteLine(b.foo()); Which version of foo is invoked in the second

print? What is the layout of class B?

Upcasting

Late binding happens because we convert a reference to an object of class B into a reference of its super-class A (upcasting):B b = new B();A a = b;

The runtime should not convert the object: only use the part inherited from A

This is different from the following implicit cast where the data is modified in the assignment:int i = 10;long l = i;

Downcasting

Once we have a reference of the super-class we may want to convert it back:A a = new B();B b = (B)a;

During downcast it is necessary to explicitly indicate which class is the target: a class may be the ancestor of many sub-classes

Again this transformation informs the compiler that the referenced object is of type B without changing the object in any way

Upcasting, downcasting

We have shown upcasting and downcasting as expressed in languages such as C++, C# and Java; though the problem is common to OO languages

Note that the upcast can be verified at compile time whereas the downcast cannot

Upcasting and downcasting don’t require runtime type checking: in Java casts are checked at runtime C++ simply changes the interpretation of an expression at

compile time without any attempt to check it at runtime

Late Binding

The output of the example depends on the language: the second output may be the result of invoking A::foo() or B::foo()

In Java the behavior would result in the invocation of B::foo

In C++ A::foo would be invoked The mechanism which associates the method

B::foo() to b.foo() is called late binding

Late Binding

In the example the compiler cannot determine statically the exact type of the object referenced by b because of upcasting

To allow the invocation of the method of the exact type rather than the one known at compile time it is necessary to pay an overhead at runtime

Programming languages allow the programmer to specify whether to apply late binding in a method invocation

In Java the keyword final is used to indicate that a method cannot be overridden in subclasses: thus the JVM may avoid late binding

In C++ only methods declared as virtual are considered for late binding

Late Binding

With inheritance it is possible to treat objects in a generic way

The benefit is evident: it is possible to write generic operations manipulating objects of types inheriting from a common ancestor

OOP languages usually support late binding of methods: which method should be invoked is determined at runtime

This mechanism involves a small runtime overhead: at runtime the type of an object should be determined in order to invoke its methods

Example (Java)

class A { final void foo() {…} void baz() {…} void bar() {…}}class B extends A { // Suppose it possible! final void foo() {…} void bar();}

A a = new A();B b = new B();A c = b;

a.foo(); // A::foo()a.baz(); // A::baz()a.bar(); // A::bar()b.foo(); // B::foo()b.bar(); // B::bar()c.foo(); // A::foo()c.bar(); // B::bar()

Abstract classes

Sometimes it is necessary to model a set S of objects which can be partitioned into subsets (A0, … An) such that their union covers S: x S Ai S, x Ai

If we use classes to model each set it is natural that A S, A<:S

Each object is an instance of a subclass of S and no object is an instance of S.

S is useful because it abstracts the commonalities among its subclasses, allowing to express generic properties about its objects.

Example

We want to manipulate documents with different formats The set of documents can be partitioned by type: doc,

pdf, txt, and so on For each document type we introduce a class that

inherits from a class Doc that represents the document In the class Doc we may store common properties to all

documents (title, location, …) Each class is responsible for reading the document

content It doesn’t make sense to have an instance of Doc though

it is useful to scan a list of documents to read

Abstract methods

Often when a class is abstract some of its methods could not be defined

Consider the method read() in the previous example

In class Doc there is no reasonable implementation for it

We leave it abstract so that through late binding the appropriate implementation will be called

Syntax

Abstract classes can be declared using the abstract keyword in Java or C#:abstract class Doc { … }

C++ assumes a class is abstract if it contains an abstract method it is impossible to instantiate an abstract class, since it will lack

that method A virtual method is abstract in C++ if its definition is

empty:virtual string Read() = 0;

In Java and C# abstract methods are annotated with abstract and no body is provided:abstract String Read();

Inheritance

Inheritance is a relation among classes Often systems impose some restriction on

inheritance relation for convenience We say that class A is an interface if all its

members are abstract; has no fields and may inherit only from one or more interfaces

Inheritance can be: Single (A <: B (C. A <: C C = B)) Mix-in (S = {B | A <: B}, 1 BS ¬interface(B)) Multiple (no restriction)

Multiple inheritance

Why systems should impose restrictions on inheritance? Multiple inheritance introduces both conceptual and implementation

issues The crucial problem, in its simplest form, is the following:

B <: A C <: A D <: B D <: C

In presence of a common ancestor: The instance part from A is shared between B and C The instance part from A is duplicated

This situation is not infrequent: in C++ ios:>istream, ios:>ostream and iostream<:istream, iostream<:ostream

The problem in sharing the ancestor A is that B and C may change the inherited state in a way that may lead to conflicts

Java and Mix-in inheritance

Both single and mix-in inheritance fix the common ancestor problem

Though single inheritance can be somewhat restrictive Mix-in inheritance has become popular with Java and

represents an intermediate solution Classes are partitioned into two sets: interfaces and

normal classes Interfaces constraints elements of the class to be only

abstract methods: no instance variables are allowed A class inherits instance variables only from one of its

ancestors avoiding the diamond problem of multiple inheritance

Implementing Single and Mix-in inheritance Consists only in combining the state of a

class and its super-classess

A A

B

A B<:A

A

B

C<:B<:A

A

B

D<:C<:B<:A

D

Note that Upcasting and Downcasting comes for free: the pointer at the base of the instance can be seen both as a pointer to an instance of A or B

Implementing multiple inheritance

With multiple inheritance becomes more complex than reinterpreting a pointer!

A A

B

A B<:A

A

C

C<:A

A

A (C)

A (B)

B

CB

CD

D

D<:B, D<:C D<:B, D<:C

Late binding

How to identify which method to invoke? Solution: use a v-table for each class that has

polymorphic methods Each virtual method is assigned a slot in the table

pointing to the method code Invoking the method involves looking up in the table at a

specific offset to retrieve the address to use in the call instruction

Each instance holds a pointer to the v-table Thus late binding incurs an overhead both in time (2

indirections) and space (one pointer per object) The overhead is small and often worth the benefits

Late binding: an example (Java)

class A { void foo() {…} void f() {…} int ai;}class B extends A { void foo() {…} void g() {…} int bi;}

foo

f

foo

f

g

A’s v-table

B’s v-table

ai

V-pointer

ai

V-pointer

bi

A a = new A();a.foo();a.f();

B b = new B();b.foo();b.g();b.f();

A c = b;c.foo();c.f();

a

b

c

JVM invokevirtual

A call like:x.equals("test")

is translated into:aload_1 ; push local variable 1 (x) onto the operand stackldc "test" ; push string "test" onto the operand stackinvokevirtual java.lang.Object.equals(Ljava.lang.Object;)Z

where java.lang.Object.equals(Ljava.lang.Object;)Z is a method specification

When invokevirtual is executed, the JVM looks at method specification and determines its # of args

From the object reference it retrieves the class, searches the list of methods for one matching the method descriptor.

If not found, searches its superclass

Invokevirtual optimization

The Java compiler can arrange every subclass method table (mtable) in the same way as its superclass, ensuring that each method is located at the same offset

The bytecode can be modified after first execution, by replacing with:invokevirtual_quick mtable-offset

Even when called on objects of different types, the method offset will be the same

Virtual Method in Interface

Optimization does not work for interfacesinterface Incrementable { public void incr(); }class Counter implements Incrementable { public void incr(); }class Timer implements Incrementable { public void decr(); public void inc(); }Incrementable i;i.incr();

Compiler cannot guarantee that method incr() is at the same offset.

Runtime type information

Execution environments may use the v-table pointer as a mean of knowing the exact type of an object at runtime

This is what happens in C++ with RTTI, in .NET CLR and JVM

Thus the cost of having exact runtime type information is allocating the v-pointer to all objects

C++ leaves the choice to the programmer: without RTTI no v-pointer is allocated in classes without virtual methods

Overloading

Overloading is the mechanism that a language may provide to bind more than one object to a name

Consider the following class:class A { void foo() {…} void foo(int i) {…}}

The name foo is overloaded and it identifies two methods

Method overloading

Overloading is mostly used for methods because the compiler may infer which version of the method should be invoked by looking at argument types

Behind the scenes the compiler generates a name for the method which includes the type of the signature (not the return type!)

This process is known as name mangling In the previous example the name foo_v may be associated to the

first method and foo_i to the second When the method is invoked the compiler looks at the types of the

arguments used in the call and chooses the appropriate version of the method

Sometimes implicit conversions may be involved and the resolution process may lead to more than one method: in this case the call is considered ambiguous and a compilation error is raised

Operator overloading

Though operators such as + and – have a syntax different from the function invocation they identify functions

C++ and other languages (i.e. C#) allow overloading these operators in the same way as ordinary functions and methods

Conceptually each invocation of + is rewritten in to the functional version and the standard overloading process is used

Example (C++):c = a + b; // operator=(c, operator+(a, b))

Late binding: an example (Java)

class A { void foo() {…} void f() {…} int ai;}class B extends A { void foo(int i) {…} void g() {…} int bi;}

foo()

f

foo()

f

g

A’s v-table

B’s v-table

ai

V-pointer

ai

V-pointer

bi

A a = new A();a.foo();a.f();

B b = new B();b.foo();b.g();b.f();

A c = b;c.foo(3);c.f();

a

b

c

foo(int)

Late binding: only on first argument

class A { void foo(A a) {…} void f() {…} int ai;}class B extends A { void foo(B b) {…} void g() {…} int bi;}

foo()

f

foo(A)

f

g

A’s v-table

B’s v-table

ai

V-pointer

ai

V-pointer

bi

A a = new A();a.foo();a.f();

B b = new B();b.foo();b.g();b.f();

A c = b;c.foo(c);c.f();

a

b

c

foo(B)