Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-12-13T00:06:13Z

Thatvamasi: /* '''Dynamic Dispatch''' */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in OOLS (Object oriented Languages and Systems). Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [http://en.wikipedia.org/wiki/Dynamic_polymorphism]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

We performed a very small experiment to see if Dynamic dispatch is practically slower than static dispatch. We opted to choose C#, since this language provide both static binding and dynamic binding. We measured the time taken to execute 1000000000 dynamically dispatched functions and statically dispatched functions. Below are our observations.

Dynamic Dispatch:
00:00:10.0995777
00:00:10.4315966
00:00:10.4675987

Static Dispatch:
00:00:10.2565866
00:00:10.3255906
00:00:10.1575809

It looks like the performance overhead of dynamic binding is negligible in today's high performing computer. Even if it Dynamic Binding needs few more instruction to perform function call, the overhead in terms of time and memory is not much of a concern, but effective software design is a matter of concern. So we can conclude that Dynamic Binding does not cause serious performance problem in present day Computers.

==Overriding and Overloading==
Overriding [http://en.wikipedia.org/wiki/Method_overriding] and Overloading [http://en.wikipedia.org/wiki/Method_overloading] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would note the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch [http://en.wikipedia.org/wiki/Multiple_dispatch].

==Multiple Dispatch==

The Multiple Dispatch is used in Common Lisp Object System (CLOS) [http://en.wikipedia.org/wiki/Common_Lisp_Object_System]. Multiple-polymorphism allows specialized functions or methods to be defined to handle various cases:

+(int, int)
+(int, float)
+(int, complex) .. etc

The above functions are specialized to each of the cases required allowing single, highly cohesive and loosely coupled functions to be defined. This is also the true essence of object-oriented polymorphism, which allows objects to define methods for each specific case desired. In addition to better coupling and cohesion, multiple-polymorphism reduces program complexity by avoiding coding logic (switch statements) and because small methods further reduce complexity, as code complexity doesn't grow linearly with lines of code per method, but perhaps exponentially.

=Conclusion=

Hence from the above discussion, we can see that Dynamic Dispatch, though slower when compared to static dispatch is no longer slower due to the new generation of power packed computers. Also, dynamic dispatch can help in preserving the object-oriented concepts in highly complex software products. We have also looked up the differences between method Overloading and Overriding. We also had a sneak-view to Multiple Dispatch where more than one parameter can be used for Dynamic method lookup.

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Multiple_dispatch Multiple Dispatch]. en.wikipedia.org. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:50:32Z

Thatvamasi: /* Conclusion */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [http://en.wikipedia.org/wiki/Method_overloading] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch [http://en.wikipedia.org/wiki/Multiple_dispatch].

==Multiple Dispatch==

The Multiple Dispatch is used in Common Lisp Object System (CLOS) [http://en.wikipedia.org/wiki/Common_Lisp_Object_System]. Multiple-polymorphism allows specialized functions or methods to be defined to handle various cases:

+(int, int)
+(int, float)
+(int, complex) .. etc

The above functions are specialized to each of the cases required allowing single, highly cohesive and loosely coupled functions to be defined. This is also the true essence of object-oriented polymorphism, which allows objects to define methods for each specific case desired. In addition to better coupling and cohesion, multiple-polymorphism reduces program complexity by avoiding coding logic (switch statements) and because small methods further reduce complexity, as code complexity doesn't grow linearly with lines of code per method, but perhaps exponentially.

=Conclusion=

Hence from the above discussion, we can see that Dynamic Dispatch, though slower when compared to static dispatch is no longer slower due to the new generation of power packed computers. Also, dynamic dispatch can help in preserving the object-oriented concepts in highly complex software products. We have also looked up the differences between method Overloading and Overriding. We also had a sneak-view to Multiple Dispatch where more than one parameter can be used for Dynamic method lookup.

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Multiple_dispatch Multiple Dispatch]. en.wikipedia.org. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:43:52Z

Thatvamasi: /* Advantages of Dynamic Binding */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [http://en.wikipedia.org/wiki/Method_overloading] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch [http://en.wikipedia.org/wiki/Multiple_dispatch].

==Multiple Dispatch==

The Multiple Dispatch is used in Common Lisp Object System (CLOS) [http://en.wikipedia.org/wiki/Common_Lisp_Object_System]. Multiple-polymorphism allows specialized functions or methods to be defined to handle various cases:

+(int, int)
+(int, float)
+(int, complex) .. etc

The above functions are specialized to each of the cases required allowing single, highly cohesive and loosely coupled functions to be defined. This is also the true essence of object-oriented polymorphism, which allows objects to define methods for each specific case desired. In addition to better coupling and cohesion, multiple-polymorphism reduces program complexity by avoiding coding logic (switch statements) and because small methods further reduce complexity, as code complexity doesn't grow linearly with lines of code per method, but perhaps exponentially.

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Multiple_dispatch Multiple Dispatch]. en.wikipedia.org. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:43:18Z

Thatvamasi: /* Multiple Dispatch */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [http://en.wikipedia.org/wiki/Method_overloading] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch [http://en.wikipedia.org/wiki/Multiple_dispatch].

==Multiple Dispatch==

The Multiple Dispatch is used in Common Lisp Object System (CLOS) [http://en.wikipedia.org/wiki/Common_Lisp_Object_System]. Multiple-polymorphism allows specialized functions or methods to be defined to handle various cases:

+(int, int)
+(int, float)
+(int, complex) .. etc

The above functions are specialized to each of the cases required allowing single, highly cohesive and loosely coupled functions to be defined. This is also the true essence of object-oriented polymorphism, which allows objects to define methods for each specific case desired. In addition to better coupling and cohesion, multiple-polymorphism reduces program complexity by avoiding coding logic (switch statements) and because small methods further reduce complexity, as code complexity doesn't grow linearly with lines of code per method, but perhaps exponentially.

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Multiple_dispatch Multiple Dispatch]. en.wikipedia.org. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:40:35Z

Thatvamasi: /* Multiple Dispatch */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [http://en.wikipedia.org/wiki/Method_overloading] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch [http://en.wikipedia.org/wiki/Multiple_dispatch].

==Multiple Dispatch==

The Multiple Dispatch is used in Common Lisp Object System (CLOS) [http://en.wikipedia.org/wiki/Common_Lisp_Object_System].

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Multiple_dispatch Multiple Dispatch]. en.wikipedia.org. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:37:57Z

Thatvamasi: /* References */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [http://en.wikipedia.org/wiki/Method_overloading] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch [http://en.wikipedia.org/wiki/Multiple_dispatch].

==Multiple Dispatch==

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Multiple_dispatch Multiple Dispatch]. en.wikipedia.org. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:37:33Z

Thatvamasi: /* References */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [http://en.wikipedia.org/wiki/Method_overloading] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch [http://en.wikipedia.org/wiki/Multiple_dispatch].

==Multiple Dispatch==

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Multiple_dispatch]. en.wikipedia.org. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:36:43Z

Thatvamasi: /* Overriding and Overloading */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [http://en.wikipedia.org/wiki/Method_overloading] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch [http://en.wikipedia.org/wiki/Multiple_dispatch].

==Multiple Dispatch==

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding Java Dynamic Binding & Method Overriding]. stackoverflow.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Multiple_dispatch]. en.wikipedia.org. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:36:04Z

Thatvamasi: /* Overriding and Overloading */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [http://en.wikipedia.org/wiki/Multiple_dispatch] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch [http://en.wikipedia.org/wiki/Multiple_dispatch].

==Multiple Dispatch==

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding Java Dynamic Binding & Method Overriding]. stackoverflow.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Multiple_dispatch]. en.wikipedia.org. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:35:15Z

Thatvamasi: /* References */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [8] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch [http://en.wikipedia.org/wiki/Multiple_dispatch].

==Multiple Dispatch==

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding Java Dynamic Binding & Method Overriding]. stackoverflow.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Multiple_dispatch]. en.wikipedia.org. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:34:30Z

Thatvamasi: /* Advantages of Dynamic Binding */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [8] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch [http://en.wikipedia.org/wiki/Multiple_dispatch].

==Multiple Dispatch==

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding Java Dynamic Binding & Method Overriding]. stackoverflow.com. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:32:48Z

Thatvamasi: /* Multiple Dispatch */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [8] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch.

==Multiple Dispatch==

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding Java Dynamic Binding & Method Overriding]. stackoverflow.com. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:32:33Z

Thatvamasi: /* Advantages of Dynamic Binding */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [8] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

One other advantage of Dynamic binding based on parameter types is that more than one parameter can be used in the selection of a method. Methods that use dynamic binding in this way are called multi-methods and the concept is called Multiple Dispatch.

=Multiple Dispatch=

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding Java Dynamic Binding & Method Overriding]. stackoverflow.com. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:17:08Z

Thatvamasi: /* Conclusion */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [8] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Advantages of Dynamic Binding=

Dynamic binding has several advantages. It provides tremendous flexibilities. Also, it allows the software to be malleable when requirements change as the system evolves. Because of dynamic binding, caller objects are not concerned how the invoked objects carry out their methods. All they need to know is that the invoked objects know how to carry out their responsibilities, but they themselves need to know only what the invoked objects can do for them. As a consequence of this, type dependencies (which are the bane of procedural programming) cannot have a ripple effect through the system, when system requirements change. The beauty is that such dependencies remain encapsulated within the objects. The flexibility that developers can derive out of this is enormous. For instance, one can install newer types without having to change or stopping the functioning of existing systems. This is something along the lines of "hot pluggable components" of the hardware cousins.

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding Java Dynamic Binding & Method Overriding]. stackoverflow.com. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-02T00:08:34Z

Thatvamasi: /* Does Dynamic Dispatching hurts in today's power packed Computers? */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [8] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Even though Dynamic Dispatching is done in run-time, and it takes good amount of memory, today's computers are power packed with good amount of memory. Hence efficiency concerns for implementing Dynamic Dispatching in OOL is of little concern.

However, the method to be called cannot be chosen based on the actual arguments passed to the function, rather, the method is called based on the declared type of the parameters.

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding Java Dynamic Binding & Method Overriding]. stackoverflow.com. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T23:44:16Z

Thatvamasi: /* Does Dynamic Dispatching hurts in today's power packed Computers? */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [8] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

==Does Dynamic Dispatching hurts in today's power packed Computers?==

Dynamic Dispatching takes

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding Java Dynamic Binding & Method Overriding]. stackoverflow.com. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T23:43:46Z

Thatvamasi: /* Overriding and Overloading */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

==Overriding and Overloading==
Overriding [2] and Overloading [8] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

=== Does Dynamic Dispatching hurts in today's power packed Computers? ===

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding Java Dynamic Binding & Method Overriding]. stackoverflow.com. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T23:38:20Z

Thatvamasi: /* Overriding and Overloading */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. Here we will make an effort to address the efficiency considerations about Dynamic Dispatch, advantages of Dynamic Dispatch using parameter types and dynamic binding in CLOS (Common Lisp Object System). 

__TOC__

=Introduction=
Dynamic Dispatch is the process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. It is generally used in Object-Oriented Language (OOL) [http://en.wikipedia.org/wiki/Object-oriented_programming]. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called as Method Overriding [http://en.wikipedia.org/wiki/Method_overriding]). When a reference to the super class is used to execute that function, then which version of the function gets executed depends on the type, the reference to which it points to at that time rather than the type of the reference. In literature it also referred to in different names like Runtime Binding or Dynamic Polymorphism. [http://en.wikipedia.org/wiki/Dynamic_polymorphism]

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

==Need for Dynamic Dispatch==
Dynamic Dispatch is one of the inherent feature of an Object-Oriented Language [1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

==How Dynamic Dispatch works?==
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment [http://en.wikipedia.org/wiki/Code_segment] area of the process image. So a function in C will just map to a memory location in Code Segment of the process image. For example calling a function 'print()', might be converted to something like 'jmp 0xFFDE123' (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal (not shown here) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.

A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementations are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to an equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable (Virtual Method Table [http://en.wikipedia.org/wiki/Virtual_method_table]) which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be changed like this by the compiler
Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

<div style="text-align: center;"> Fig.1 - VTable Working </div>

 
Virtual Method table or vtable or dispatch table [5] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=Performance Evaluation=
From the above explanation it is evident that Virtual functions [http://en.wikipedia.org/wiki/Virtual_function] [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm] are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the Virtual method table [5] and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reasons why not all functions are dynamically binded in C++. In C++, functions which are explicitly marked virtual are dynamically bound whereas remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, hence, all functions are dynamically bound. It is also reasonable to assume that virtual functions might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

=== Overriding and Overloading ===
Overriding [2] and Overloading [8] are two different features of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version of the function to call is deferred till runtime.

Let us see an two examples which provides insight into Overriding and Overloading.

Example - 1: Overloading

public class A{
public boolean equals( A check){ # Equals method of parameter type A
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # Object equals method called
a2.equals(a1); # Object equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # Object equals method called
}
}

Example - 2: Overriding

public class A{
@Override
public boolean equals( Object check){ # Equals method of parameter type Object
System.out.println( "A.equals method called");
return true;
}

public static void main(String [] args){ # Main method
Object a1 = new A(); # Instantiate class to get objects
A a2 = new A();
Object o1 = new Object();

a1.equals(a2); # A equals method called
a2.equals(a1); # A equals method called
a2.equals(a2); # A equals method called
a2.equals(o1); # A equals method called
}
}

If you see the comments provided to the side of the method calls, you would notify the difference in the equals method called in case of both Overloading and Overriding. The decision which method to use, basically has two phases: First overload resolution, then method dispatch. Overload resolution happens at compile-time, method dispatch at runtime.

=== Does Dynamic Dispatching hurts in today's power packed Computers? ===

=Conclusion=

=Further Reading=

=References=
# [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overriding Method Overriding]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Code_segment Code Segment]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_method_table Virtual Method Table]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Virtual_function Virtual Functions]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc14cplr139.htm Virtual Functions in C++]. publib.boulder.ibm.com. Retrieved Oct 31, 2010.
# [http://en.wikipedia.org/wiki/Method_overloading Method Overloading]. en.wikipedia.org. Retrieved Oct 31, 2010.
# [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding Java Dynamic Binding & Method Overriding]. stackoverflow.com. Retrieved Oct 31, 2010.

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T15:41:35Z

Thatvamasi: /* How Dynamic Dispatch works? */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T01:09:56Z

Thatvamasi: /* References */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T01:09:40Z

Thatvamasi: /* Overriding and Overloading */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T01:06:42Z

Thatvamasi: /* References */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T01:05:13Z

Thatvamasi: /* References */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T01:02:52Z

Thatvamasi: /* Performance Evaluation */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T01:02:14Z

Thatvamasi: /* Performance Evaluation */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T00:53:53Z

Thatvamasi: /* How Dynamic Dispatch works? */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T00:50:48Z

Thatvamasi: /* How Dynamic Dispatch works? */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T00:49:25Z

Thatvamasi: /* How Dynamic Dispatch works? */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-11-01T00:48:20Z

Thatvamasi: /* How Dynamic Dispatch works? */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T22:19:41Z

Thatvamasi: /* References */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T22:19:26Z

Thatvamasi: /* Further Reading */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T22:19:07Z

Thatvamasi: /* Conclusion */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T22:18:31Z

Thatvamasi: /* Performance Evaluation */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T22:18:11Z

Thatvamasi: /* Performance Evaluation */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T22:17:46Z

Thatvamasi: /* How Dynamic Dispatch works */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T22:17:15Z

Thatvamasi: /* How Dynamic Dispatch works */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T22:16:47Z

Thatvamasi: /* Why we need Dynamic Dispatch */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T17:13:07Z

Thatvamasi: /* Introduction */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T17:12:25Z

Thatvamasi: /* Why we need Dynamic Dispatch */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T17:09:35Z

Thatvamasi: /* References */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T17:03:13Z

Thatvamasi: /* Introduction */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T16:25:51Z

Thatvamasi: /* '''Dynamic Dispatch''' */

CSC/ECE 517 Fall 2010/ch2 5c gn

2010-10-31T15:58:56Z

Thatvamasi: /* Dynamic Dispatch */

='''Dynamic Dispatch'''=

This wiki-page serves as a knowledge source for understanding the concept of Dynamic Dispatch in Computer Science. 

__TOC__

=== Introduction ===
The process of identifying which version of the function to call based on the runtime type of the reference being used to execute the function. Dynamic Dispatch generally happens in OOL. For example, we can have a super class which defines a particular function and then there is a subclass which defines the same function (called overriding). When a reference to the super class is used to execute that function, then which version of the function gets execute depends on the type, the reference points to at that time, instead of type of the reference. In literature it also given different names like Runtime Binding or [http://en.wikipedia.org/wiki/Dynamic_polymorphism Dynamic Polymorphism ].

To further understand what Dynamic Dispatch is, consider the below example:

class Animal {
public void walk() {
System.out.println("Animal::walk");
}
}

class Dog extends Animal {
public void walk() {
System.out.println("Dog::walk");
}
}

class Cat extends Animal {
public void walk() {
System.out.println("Cat::walk");
}
}

Animal a = new _______();
a.walk();

The compiler cannot decide which version of walk (Animal, Dog or Cat) during compile time. So the decision of which version of the walk function to call will be deferred till the runtime.

=== Why we need Dynamic Dispatch ===
Dynamic Dispatch is one of the inherent feature of an Object Oriented Languauge [http://en.wikipedia.org/wiki/Object_oriented_language 1]. In a reasonably large software based on a procedural language like C, you will come across a bunch of switch or if statement which decides which version of the function to call. Ofcourse Dynamic Dispatch can be simulated in a procedural language like C, but it involves dangerous pointer manipulation, which is usually done well by the Compilers in case of OOL like C++.

For example, consider a toll gate application which charges differently based on the car type like Sedan, SUV, Coupe etc., If we have to do this in a procedural language like C in which each classes of car represented by structure, we might have something like this.

float calculate_charge(void *car, int type)
{
switch(type)
{
case SUV:
return suv_charge(car);
case SEDAN:
return sedan_charge(car);
case COUPE:
return coupe_charge(car);
}

You can see that the code above will quickly becomes messy as we define new type of car. If we have done the same in an OOL language like Java the above statement could be replacement by a simple:

car.charge();

The function charge will be overridden in each of the subclasses (Sedan, Suv, and Coupe). From the above example it is very evident that why we need dynamic dispatch and it is obviously useful.

=== How Dynamic Dispatch works ===
The implementation of Dynamic Dispatch varies significantly based on type language, in fact it changes even from Compiler to Compiler for a same language. We will consider how function are dispatch at runtime in both C and C++. We will try to understand if there is any overhead involved with virtual functions.

In a machine compiled language like C, program logic is compiled into underlying processor instruction set by the compiler. Incase of x86 compiler, C code will be compiled into X86 instruction sets. The function will be compiled and placed in Code Segment area of the process image. So a function in C will just map to a memory location in Code Segment of the process image.

For example calling a function print(), might be converted to something like jmp 0xFFDE123 (jmp is a branching instruction). So a function call is in fact as simple as executing a jump statement (of course you push the arguments into stack before you call jump).

Now lets consider a OOL like C++ which too compiles to hardware instruction set on compilation. Consider the below example of two classes which extend from a common class called Animal(not shown) with one method talk. The below example just demonstrates how dynamic dispatch could be implemented by a compiler.
A word of caution before you proceed; the implementation is hypothetical and far from any practical use. The objective of the example shown below is just to give an idea of how Dynamic Dispatch might be implemented. Practical implementation are lot more complicated, so we have taken this simple example for easy explanation and understanding.

class Cat
{
public:
void talk()
{
cout << "Meow!!";
}
};

class Dog
{
public:
void talk()
{
cout << "Bark!!";
}
};

The above C++ program might infact be converted to a equivalent C program by the compiler during pre-compilation. Each newly defined structure gets an __id__ and this id will be used to lookup vtable which maps id to the actual function memory location. One we get the memory location we will execute a jump instruction like we did before.

struct Cat
{
int __id__; // 0
char name[10];
};

struct Dog
{
int __id__; // 1
char name[10];
};

void cat_talk()
{
printf("meow!");
}

void dog_talk()
{
printf("Bark!!");
}

void talk(void *object)
{
int id = *(int *)object;
vtable[id]();
}

void (*vtable[2]);
vtable[0] = cat_talk;
vtable[1] = dog_talk;

// C++ function call like
Animal *d = new Dog();
d->talk();

// might be change like this by the compiler

Dog *d = malloc(sizeof(Dog));
d->__id__ = 1;
talk(d);

// talk function can use the __id__ attribute to offset into the vtable to identify which version of function to call.

[[Image:Vtable.png|frame|center]]

virtual method table or [http://en.wikipedia.org/wiki/Virtual_method_table vtable] is the key to virtual function working. It is evident from the above that vtable infact makes the function calling little more expensive compared to normal function calls.

=== Performance Evaluation ===
From the above explanation it is evident that virtual functions are more complicated that dispatching normal function calls. For example Virtual functions in C++ will need extra memory for each class to store the virtual method table and needs additional CPU cycles to perform vtable lookup, before it can make the actual function call.

This is one of the important reason why not all functions are dynamic bind in C++. In C++, functions which are explicitly marked virtual are dynamically bound, remaining functions are statically bound during the compile time. When we say bound/bind we are actually talking about the mapping between the function name and memory location where it is stored for execution.

In languages like Java, the creators thought dynamic binding being an essential feature of OOL, all functions are dynamically bound. It also reasonable to assume that virtual function might need 20 to 40 extra instruction sets to execute a function call. Given today's processors speed this might be very insignificant.

--------try to find a performance comparison and discuss about that---------

=== Overriding and Overloading ===
Overriding and Overloading are two different feature of OOL. In function overloading, which version of function to call is decided by the compiler during the compile time itself, where as when a function is overridden, which version to call is deferred till runtime. [http://stackoverflow.com/questions/321864/java-dynamic-binding-and-method-overriding This]provides an interesting discussion about this fact.

=== Does Dynamic Dispatching hurts in today's power packed Computers? ===
=== Conclusion ===
=== Further Reading ===
=== References ===
*[http://en.wikipedia.org/wiki/Object_oriented_language 1. Wikipedia - Object Oriented Language]

CSC/ECE 517 Fall 2010/ch1 1f vn

2010-09-18T01:51:30Z

Thatvamasi: /* Example */

='''Unit-Testing Frameworks for Ruby'''=

This wiki-page serves as a knowledge source for understanding the different Unit-Testing Frameworks available for Ruby. 

__TOC__

=Introduction=
Unit testing is a method by which we can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written. [http://en.wikipedia.org/wiki/Unit_testing] It helps to identify errors in the program even without running the entire program. It also helps to do regressing testing to identify buggy code additions in the future. Unit testing frameworks provides us with constructs which simplifies the process of unit testing. Using a standard unit test framework helps other developers to add test cases easily. [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing] This chapter walks through three different unit testing frameworks available for Ruby and explains how to use them with examples. The three commonly used unit testing frameworks for ruby are

# Test::Unit
# Shoulda
# RSpec

=Test::Unit=

Now we shall consider Test::Unit framework

==Background==
Ruby comes with an in-built, ready to use unit testing framework called Test::Unit. It is a XUnit type framework and typically have a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests themselves are bundled separately in a test class from the code it is testing.

==Test Fixture==
Test fixture represents the initial environment setup(eg. initialization data) and/or the expected outcome of the tests for that environment. This is typically done in the setup() and teardown() methods and it helps to separate test initialization and cleanup from the actual tests. It also helps to reuse the same fixture for more than one tests.[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html]

For example, consider a method prime_check(num) which takes an integer number as input and outputs whether it is prime number or not. In order to unit test this method we can create the following fixture containing a 2-dimensional array with a number and the expected output of whether it is prime or not.

def setup
@NUMBERS = [[3,true], [4,false], [7,true], [10,false]]
end

==Assertions==
The core part of test::unit framework is the ability to assert a statement of expected outcome. If an assert statement is correct then the test will proceed, otherwise the test will fail. This feature helps us to verify the method under test with different types of inputs and track the results. Test::unit provides a bunch of assert methods for this purpose:

{| border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

For the full list of assertion methods provided by test::unit refer to test::unit assertions. [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html]

==Example==
The test case class BinarySearchTest subclasses the Test::Unit::TestCase class and overrides setup and teardown methods. The test methods should start with 'test_' prefix. This helps in isolating the test methods from the helper methods if any. The Test::Unit::TestCase class takes care of making the test methods into tests, wrapping them into a suite and running the individual tests. The test results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

def setup
@input_array = [1,2,3,4,5] #The test fixture is initialized
end

def test_success_left_half
assert_equal(binary_search(@input_array,1),true) #tests if the element present in left half of the array is found
assert_equal(binary_search(@input_array,2),true)
end

def test_success_right_half
assert_equal(binary_search(@input_array,5),true) #tests if the element present in the right half of the array is found
assert_equal(binary_search(@input_array,4),true)
end

def test_success_middle #tests if the element present in the middle of the array is found
assert_equal(binary_search(@input_array,3),true)
end

def test_failure
assert_equal(binary_search(@input_array,6),false) #tests if an element not present in the array is not found
end

def teardown
#nothing to do here
end

end

Here we have four test methods testing different logical paths of the binary search algorithm. Each test method can have one or more assert statements to test whether conditions are correct in each situation. To run the tests we simply have to run the file binary_search_test.rb and the output is as follows:

Loaded suite binarysearch
Started
F...
Finished in 0.372 seconds.

1) Failure:
test_failure(BinarySearchTest) [binarysearch.rb:25]:
<true> expected but was
<false>.

4 tests, 6 assertions, 1 failures, 0 errors

The results show that the last test case test_failure, testing the negative scenario is failing. The reason is because the assert statement is expecting false when number 6, which not present in the array is passed. But the binary_search method is returning true.

==Test Suite==
Sometimes it is useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose. The below example demonstrates how to bundle binary and sequential test case classes into a single search test suite.

require 'test/unit/testsuite'
require 'binary_search_test'
require 'sequential_search_test'

class Search_Tests
def self.suite
suite = Test::Unit::TestSuite.new
suite << BinarySearchTest.suite
suite << SequentialSearchTest.suite
return suite
end
end
Test::Unit::UI::Console::TestRunner.run(Search_Tests)

=Shoulda=

==Background==
One of the downsides of Test::Unit is we end up writing lots of code in order to test the actual code which is sometimes not easy to understand. Shoulda is a library that allows us to write better and more understandable tests for ruby application. Shoulda is not a testing framework by itself. It extends the Test::Unit framework with the idea of context. We can mix Test::Unit test cases with Shoulda test cases. Shoulda allows us to provide context to the tests so that we can group the tests according to a specific feature or scenario. [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html]

==Example==
require 'shoulda'
require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

context "Input array of size 5" do

def setup
@input_array = [1,2,3,4,5]
end

should "have the number in the left half of the array" do #tests if the element present in left half of the array is found
assert_equal(binary_search(@input_array,1),true)
assert_equal(binary_search(@input_array,2),true)
end

should "have the number in the right half of the array" do #tests if the element present in right half of the array is found
assert_equal(binary_search(@input_array,5),true)
assert_equal(binary_search(@input_array,4),true)
end

should "have the number in the middle of the array" do #tests if the element present in middle of the array is found
assert_equal(binary_search(@input_array,3),true)
end

should "not have the number in the array" do #tests if the element not present in the array is not found
assert_equal(binary_search(@input_array,6),false)
end

def teardown
#nothing to do here
end
end

context "Input array of size 1" do

def setup
@input_array = [1]
end

should "have the number in the array" do
assert_equal(binary_search(@input_array,1),true) #tests if an element is found in the single element array
end

should "not have the number in the array" do # tests if an element is not found in the single element array
assert_equal(binary_search(@input_array,2),true)
end

def teardown
#nothing to do here
end
end
end

Notice that we are still sub-classing the Test::Unit::TestCase class. In this example we have two contexts one for input array of size 5 and the other for input array of size 1. Each context has its own environment of setup/teardown methods. We can also create nested contexts - the outer setup gets run before the execution of each of the inner contexts. And the setup in the inner contexts gets run when running that context. Each should construct is converted into individual test methods and are run. If a test case fails we will get a better description of what that test case is doing from the should description.

=RSpec=

Now let us consider about RSpec Testing Framework in detail.

==Background==

Behaviour Driven Development (BDD) [http://en.wikipedia.org/wiki/Behavior_Driven_Development] is an Agile development process [http://en.wikipedia.org/wiki/Agile_software_development] that comprises aspects of Acceptance Test Driven Planning [http://www.springerlink.com/content/978-3-540-22839-4/] [http://en.wikipedia.org/wiki/Acceptance_testing], Domain Driven Design [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Domain-driven_design] and Test Driven Development (TDD). [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Test-driven_development] RSpec is a Behavioural Driven Development (BDD) tool aimed at Test Driven Development, originally created by Dave Astels and Steven Baker. However David Chelimsky [http://blog.davidchelimsky.net/] is really the gatekeeper of the RSpec project. [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]

Traditionally we use Unit Test frameworks like JUnit, NUnit or RUnit for writing Test cases. We spend a lot of time writing tests that test every unit of code in our software system. Instead we can shift our focus from Unit testing to Behaviour testing or Behaviour Driven Development (BDD) using RSpec. By focusing on the behaviour of the system it helps clarify in our minds what the system should actually be doing. It also helps us to perform more ‘useful’ tests. Useful tests, cover what the system should be doing and build in enough redundancy so that it should be easy to refactor our code without having to re-write every test. 

RSpec is really two projects merged into one. The RSpec project pages describes these merged projects as:

# application level behaviour described by a Story Framework 
# object level behaviour described by a Spec Framework 

Dan North created rbehave [http://blog.dannorth.net/2007/06/17/introducing-rbehave/] which is the Story Framework and David Chelimsky created the Spec Framework. By encompassing two frameworks RSpec equips a programmer with a thorough set of testing tools, allowing you to think about your software problem from a number of perspectives.

==Prerequisites==

The prerequisites are

# Ruby 1.8.4 or later
# RSpec Gem (latest)

To install Ruby, please visit official Ruby Website [http://www.ruby-lang.org/] 
To install RSpec, open a command shell, go to /bin folder in Ruby directory and type 
> gem install rspec

==Terms & Definitions==

Here are some terms which are used frequently while working with RSpec. [http://www.pragprog.com/titles/achbd/the-rspec-book/ ]

# subject code - The code whose behavior is specified using RSpec
# expectation - The expected behavior of subject code is expressed using expectation (Similar to 'Assertions' statements used in Test::Unit or other tools in other languages)
# code example - An executable example containing the subject code and the expectations (Similar to 'Test Method' terminology used elsewhere)
# example group - A group of code examples (Similar to 'Test Case' terminology used elsewhere)
# spec file - A file which contains one or more example groups

==Example==

Let us go through an example to be clear on the usage of RSpec.

require 'binarysearch'

describe BinarySearchTest do
before(:all) do
@input_array = [1, 2, 3, 4, 5] # The Input Array
end

after(:all) do
# do nothing here
end

it "should be in the left-half of the array" do # Test case for element to be present in left-half of given array
bst = BinarySearch.new
bst.should be_binary_search(1)
end

it "should be in the right-half of the array" do # Test case for element to be present in right-half of given array
bst = BinarySearch.new
bst.should be_binary_search(5)
end

it "should be in the middle of the array" do # Test case for element to be present in the middle of given array
bst = BinarySearch.new
bst.should be_binary_search(3)
end

it "should not be in the array"
end

Here it is assumed that the method binary_search will return true/false based on whether the provided value exists in the array or not. It should produce the following output. The un-implemented tests are marked as Pending in the output.

BinarySearchTest
- should be in the left-half of the array
- should be in the right-half of the array
- should be in the middle of the array
- should not be in the array (PENDING: Not Yet Implemented)

Pending:
BinaryTestSearch should not be in the array (Not Yet Implemented)
Called from binarysearch.rb:27

Finished in 0.006682 seconds

4 examples, 0 failures, 1 pending

====describe() method====

The describe() method can take an arbitrary number of arguments and a block and returns a sub-class of Spec::Example::ExampleGroup. We generally use only one or two arguments which is used to describe the behavior. The first argument can be a reference to a Class or module or a string. The second argument is optional and should be a string when used.

====it() method====

Similar to the describe() method, the it() method takes a single String, an optional Hash and an optional block. The String expression within the it() should be such that it informs the behavior of the code within the block.

==Expectations in RSpec==

There are two methods available for checking expectations: should() and should_not(). Both the methods accept either an expression matcher or a Ruby expression using a specific subset of Ruby operators. An expression matcher is an objects that matches an expression.

===Built-in Matchers===

There are several matchers that can be used with should and should_not, which are divided into well-separated categories.
====Equality====
subject.should == ece517
subject.should === ece517
subject.should eql(subject)
subject.should equal(subject)

The == method is used to express equivalence and equal is used when you want the receiver and the argument to be the same object. Instead of using !=, you should use the should_not method!

====Floating Point Calculations====
piValue.should be_close(3.14, 0.001593)

Sometimes the values generated might be correct upto some fixed decimal positions, after that they may have slight variations. To avoid the test beings failed, we provide the (value, delta) to be_close method which passes the test if the obtained value lies within the range (value+delta).

====Regular Expressions====
resultExpression.should match(/this regular expression/)
resultExpression.should =~ /this regular expression/

This can be very useful when dealing with multiple-line expectations, instead of using the open file technique to compare contents.

====Changes====
lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.to(1)

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.from(0).to(1)

This is really useful when working with database changes or changes to objects. The matcher is change(), which takes a block and accepts the from(), to() or by() modifiers. [18]

====Errors====
field = CricketGround.new(:players => 11)
lambda {
field.remove(:players, 15)
}.should raise_error(NotEnoughPlayers,“attempted to remove more players than there is on cricket stadium”)

Useful when needed to check for Exceptions. The matcher is raise_error and takes an ExceptionObject and/or a String/Regexp.

====Throw====
speech = Speech.new(:seats => 100)
100.times { speech.register Person.new }
lambda {
speech.register Person.new
}.should throw_symbol(:speech_full, 100)

When dealing with “errors that are not really exceptions”, you use catch and throw. Rspec can check if a throw has been called by using the throw_symbol matcher. It accepts 0,1 or 2 arguments. The first argument needs to be a Symbol and the second can be any Object that is thrown along.

===Predicate Matchers===
A Ruby predicate method is a method that ends with a “?” and returns a boolean value, like string.empty? or regexp.match? methods. Instead of writing:
a_string.empty?.should == true
We can write using RSpec:
a_string.should be_empty

When using a be_something matcher, RSpec removes the “be_”, appends a “?” and calls the resulting method in the receiver. A very common construct of this method is be_true, which checks if the receiver is true (any object except false or nil) or false (false or nil).

===Check Ownership===
Sometimes you will want to check something the object owns and not the object itself.

====The have_something() method====
security_access.has_key?(:id).should == true
is the same as
security_access.should have_key(:id)

RSpec uses method_missing to convert anything that begins with have_something to has_something? and performs the checking.

====The have() method====
field.players.select {|p| p.team == home_team }.length.should == 9
is the same as
home_team.should have(9).players_on(field)

As have() does not respond to players_on(), it delegates to the receiver (home_team). It encourages the home_team object to have useful methods like players_on. 
You can get a NoMethodError if the players_on method doesn´t exist, you can get another NoMethodError if the result of the players_on method doesn´t respond to size() or length() and if the size of the collection doesn´t match the expected size, you will get a failed expectation. [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/]

===Checking Collections Themselves===
Sometimes we create expectations about a collection itself and not about an owned collection. RSpec lets us use the have() method to express this as well, as in:
basket_collection.should have(10).items
items is just providing some meaning to the expectation.

====Strings====
Strings are not collections by definition but they respond to a lot of methods that collections do, like length() and size(). This allow us to use have() to expect a string of a specific length.
“apple”.should have(5).characters
characters is just providing meaning to the expectation as well.

====Have() modifiers for precision====
The have() method has some relatives that allow us to check for upper and lower conditions.

work.should have_exactly(8).hours
classroom.should have_at_most(100).people
bag.should have_at_least(5).items

===Operator Expressions===
There may be sometimes when you want to expect a value to be not an exact amount but something like greater than or less than. RSpec allows you to do this by using the regular operators from Ruby!

number.should == 3
number.should be >= 2
number.should be <= 4
number should be > 0

=References=

# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Programming & Unit Testing]. en.wikibooks.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Ruby Test::Unit]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Ruby Assertions]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html Shoulda Explained]. pragprog.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavior Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://www.springerlink.com/content/978-3-540-22839-4/ Proceedings of Extreme Programming and Agile Methods Conference] Carmen Zannier, Hakan Erdogmus and Lowell Lindstrom. Extreme Programming and Agile Methods - XP/Agile Universe 2004. 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, August 15-18, 2004.
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false Domain-driven design: tackling complexity in the heart of software]. By Eric Evans. books.google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Domain-driven_design Domain Driven Design]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false Test-driven development: by example]. By Kent Beck. books. google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://blog.davidchelimsky.net/ David Chelimsky Blog]. davidchelimsky.net. Retrieved Sep 17, 2010.
# [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/ Understanding RSpec Stories - A Tutorial]. emson.co.uk. Retrieved Sep 17, 2010.
# [http://blog.dannorth.net/2007/06/17/introducing-rbehave/ rbehave]. dannorth.net. Retrieved Sep 17, 2010.
# [http://www.ruby-lang.org Ruby Website]. ruby-lang.org. Retrieved Sep 17, 2010.
# [http://www.pragprog.com/titles/achbd/the-rspec-book RSpec Book]. pragprog.com. Retrieved Sep 17, 2010.
# [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/ RSpec - Expectations]. wordpress.com. Retrieved Sep 17, 2010.

CSC/ECE 517 Fall 2010/ch1 1f vn

2010-09-18T01:49:57Z

Thatvamasi: /* Example */

='''Unit-Testing Frameworks for Ruby'''=

This wiki-page serves as a knowledge source for understanding the different Unit-Testing Frameworks available for Ruby. 

__TOC__

=Introduction=
Unit testing is a method by which we can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written. [http://en.wikipedia.org/wiki/Unit_testing] It helps to identify errors in the program even without running the entire program. It also helps to do regressing testing to identify buggy code additions in the future. Unit testing frameworks provides us with constructs which simplifies the process of unit testing. Using a standard unit test framework helps other developers to add test cases easily. [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing] This chapter walks through three different unit testing frameworks available for Ruby and explains how to use them with examples. The three commonly used unit testing frameworks for ruby are

# Test::Unit
# Shoulda
# RSpec

=Test::Unit=

Now we shall consider Test::Unit framework

==Background==
Ruby comes with an in-built, ready to use unit testing framework called Test::Unit. It is a XUnit type framework and typically have a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests themselves are bundled separately in a test class from the code it is testing.

==Test Fixture==
Test fixture represents the initial environment setup(eg. initialization data) and/or the expected outcome of the tests for that environment. This is typically done in the setup() and teardown() methods and it helps to separate test initialization and cleanup from the actual tests. It also helps to reuse the same fixture for more than one tests.[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html]

For example, consider a method prime_check(num) which takes an integer number as input and outputs whether it is prime number or not. In order to unit test this method we can create the following fixture containing a 2-dimensional array with a number and the expected output of whether it is prime or not.

def setup
@NUMBERS = [[3,true], [4,false], [7,true], [10,false]]
end

==Assertions==
The core part of test::unit framework is the ability to assert a statement of expected outcome. If an assert statement is correct then the test will proceed, otherwise the test will fail. This feature helps us to verify the method under test with different types of inputs and track the results. Test::unit provides a bunch of assert methods for this purpose:

{| border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

For the full list of assertion methods provided by test::unit refer to test::unit assertions. [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html]

==Example==
The test case class BinarySearchTest subclasses the Test::Unit::TestCase class and overrides setup and teardown methods. The test methods should start with 'test_' prefix. This helps in isolating the test methods from the helper methods if any. The Test::Unit::TestCase class takes care of making the test methods into tests, wrapping them into a suite and running the individual tests. The test results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

def setup
@input_array = [1,2,3,4,5] #The test fixture is initialized
end

def test_success_left_half
assert_equal(binary_search(@input_array,1),true) #tests if the element present in left half of the array is found
assert_equal(binary_search(@input_array,2),true)
end

def test_success_right_half
assert_equal(binary_search(@input_array,5),true) #tests if the element present in the right half of the array is found
assert_equal(binary_search(@input_array,4),true)
end

def test_success_middle #tests if the element present in the middle of the array is found
assert_equal(binary_search(@input_array,3),true)
end

def test_failure
assert_equal(binary_search(@input_array,6),false) #tests if an element not present in the array is not found
end

def teardown
#nothing to do here
end

end

Here we have four test methods testing different logical paths of the binary search algorithm. Each test method can have one or more assert statements to test whether conditions are correct in each situation. To run the tests we simply have to run the file binary_search_test.rb and the output is as follows:

Loaded suite binarysearch
Started
F...
Finished in 0.372 seconds.

1) Failure:
test_failure(BinarySearchTest) [binarysearch.rb:25]:
<true> expected but was
<false>.

4 tests, 6 assertions, 1 failures, 0 errors

The results show that the last test case test_failure, testing the negative scenario is failing. The reason is because the assert statement is expecting false when number 6, which not present in the array is passed. But the binary_search method is returning true.

==Test Suite==
Sometimes it is useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose. The below example demonstrates how to bundle binary and sequential test case classes into a single search test suite.

require 'test/unit/testsuite'
require 'binary_search_test'
require 'sequential_search_test'

class Search_Tests
def self.suite
suite = Test::Unit::TestSuite.new
suite << BinarySearchTest.suite
suite << SequentialSearchTest.suite
return suite
end
end
Test::Unit::UI::Console::TestRunner.run(Search_Tests)

=Shoulda=

==Background==
One of the downsides of Test::Unit is we end up writing lots of code in order to test the actual code which is sometimes not easy to understand. Shoulda is a library that allows us to write better and more understandable tests for ruby application. Shoulda is not a testing framework by itself. It extends the Test::Unit framework with the idea of context. We can mix Test::Unit test cases with Shoulda test cases. Shoulda allows us to provide context to the tests so that we can group the tests according to a specific feature or scenario. [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html]

==Example==
require 'shoulda'
require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

context "Input array of size 5" do

def setup
@input_array = [1,2,3,4,5]
end

should "have the number in the left half of the array" do #tests if the element present in left half of the array is found
assert_equal(binary_search(@input_array,1),true)
assert_equal(binary_search(@input_array,2),true)
end

should "have the number in the right half of the array" do #tests if the element present in right half of the array is found
assert_equal(binary_search(@input_array,5),true)
assert_equal(binary_search(@input_array,4),true)
end

should "have the number in the middle of the array" do #tests if the element present in middle of the array is found
assert_equal(binary_search(@input_array,3),true)
end

should "not have the number in the array" do #tests if the element not present in the array is not found
assert_equal(binary_search(@input_array,6),false)
end

def teardown
#nothing to do here
end
end

context "Input array of size 1" do

def setup
@input_array = [1]
end

should "have the number in the array" do
assert_equal(binary_search(@input_array,1),true) #tests if an element is found in the single element array
end

should "not have the number in the array" do # tests if an element is not found in the single element array
assert_equal(binary_search(@input_array,2),true)
end

def teardown
#nothing to do here
end
end
end

Notice that we are still sub-classing the Test::Unit::TestCase class. In this example we have two contexts one for input array of size 5 and the other for input array of size 1. Each context has its own environment of setup/teardown methods. We can also create nested contexts - the outer setup gets run before the execution of each of the inner contexts. And the setup in the inner contexts gets run when running that context. Each should construct is converted into individual test methods and are run. If a test case fails we will get a better description of what that test case is doing from the should description.

=RSpec=

Now let us consider about RSpec Testing Framework in detail.

==Background==

Behaviour Driven Development (BDD) [http://en.wikipedia.org/wiki/Behavior_Driven_Development] is an Agile development process [http://en.wikipedia.org/wiki/Agile_software_development] that comprises aspects of Acceptance Test Driven Planning [http://www.springerlink.com/content/978-3-540-22839-4/] [http://en.wikipedia.org/wiki/Acceptance_testing], Domain Driven Design [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Domain-driven_design] and Test Driven Development (TDD). [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Test-driven_development] RSpec is a Behavioural Driven Development (BDD) tool aimed at Test Driven Development, originally created by Dave Astels and Steven Baker. However David Chelimsky [http://blog.davidchelimsky.net/] is really the gatekeeper of the RSpec project. [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]

Traditionally we use Unit Test frameworks like JUnit, NUnit or RUnit for writing Test cases. We spend a lot of time writing tests that test every unit of code in our software system. Instead we can shift our focus from Unit testing to Behaviour testing or Behaviour Driven Development (BDD) using RSpec. By focusing on the behaviour of the system it helps clarify in our minds what the system should actually be doing. It also helps us to perform more ‘useful’ tests. Useful tests, cover what the system should be doing and build in enough redundancy so that it should be easy to refactor our code without having to re-write every test. 

RSpec is really two projects merged into one. The RSpec project pages describes these merged projects as:

# application level behaviour described by a Story Framework 
# object level behaviour described by a Spec Framework 

Dan North created rbehave [http://blog.dannorth.net/2007/06/17/introducing-rbehave/] which is the Story Framework and David Chelimsky created the Spec Framework. By encompassing two frameworks RSpec equips a programmer with a thorough set of testing tools, allowing you to think about your software problem from a number of perspectives.

==Prerequisites==

The prerequisites are

# Ruby 1.8.4 or later
# RSpec Gem (latest)

To install Ruby, please visit official Ruby Website [http://www.ruby-lang.org/] 
To install RSpec, open a command shell, go to /bin folder in Ruby directory and type 
> gem install rspec

==Terms & Definitions==

Here are some terms which are used frequently while working with RSpec. [http://www.pragprog.com/titles/achbd/the-rspec-book/ ]

# subject code - The code whose behavior is specified using RSpec
# expectation - The expected behavior of subject code is expressed using expectation (Similar to 'Assertions' statements used in Test::Unit or other tools in other languages)
# code example - An executable example containing the subject code and the expectations (Similar to 'Test Method' terminology used elsewhere)
# example group - A group of code examples (Similar to 'Test Case' terminology used elsewhere)
# spec file - A file which contains one or more example groups

==Example==

Let us go through an example to be clear on the usage of RSpec.

require 'binarysearch'

describe BinarySearchTest do
before(:all) do
@input_array = [1, 2, 3, 4, 5] # The Input Array
end

after(:all) do
# do nothing here
end

it "should be in the left-half of the array" do # Test case for element to be present in left-half of given array
bst = BinarySearch.new
bst.should be_binary_search(1)
end

it "should be in the right-half of the array" do # Test case for element to be present in right-half of given array
bst = BinarySearch.new
bst.should be_binary_search(5)
end

it "should be in the middle of the array" do # Test case for element to be present in the middle of given array
bst = BinarySearch.new
bst.should be_binary_search(3)
end

it "should not be in the array"
end

Here it is assumed that the method binary_search will return true/false based on whether the provided value exists in the array or not. It should produce the following output. The un-implemented tests are marked as Pending in the output.

BinarySearchTest
- should be in the left-half of the array
- should be in the right-half of the array
- should be in the middle of the array
- should not be in the array (PENDING: Not Yet Implemented)

Pending:
BinaryTestSearch should not be in the array (Not Yet Implemented)
Called from binarysearch.rb:22

Finished in 0.006682 seconds

4 examples, 0 failures, 1 pending

====describe() method====

The describe() method can take an arbitrary number of arguments and a block and returns a sub-class of Spec::Example::ExampleGroup. We generally use only one or two arguments which is used to describe the behavior. The first argument can be a reference to a Class or module or a string. The second argument is optional and should be a string when used.

====it() method====

Similar to the describe() method, the it() method takes a single String, an optional Hash and an optional block. The String expression within the it() should be such that it informs the behavior of the code within the block.

==Expectations in RSpec==

There are two methods available for checking expectations: should() and should_not(). Both the methods accept either an expression matcher or a Ruby expression using a specific subset of Ruby operators. An expression matcher is an objects that matches an expression.

===Built-in Matchers===

There are several matchers that can be used with should and should_not, which are divided into well-separated categories.
====Equality====
subject.should == ece517
subject.should === ece517
subject.should eql(subject)
subject.should equal(subject)

The == method is used to express equivalence and equal is used when you want the receiver and the argument to be the same object. Instead of using !=, you should use the should_not method!

====Floating Point Calculations====
piValue.should be_close(3.14, 0.001593)

Sometimes the values generated might be correct upto some fixed decimal positions, after that they may have slight variations. To avoid the test beings failed, we provide the (value, delta) to be_close method which passes the test if the obtained value lies within the range (value+delta).

====Regular Expressions====
resultExpression.should match(/this regular expression/)
resultExpression.should =~ /this regular expression/

This can be very useful when dealing with multiple-line expectations, instead of using the open file technique to compare contents.

====Changes====
lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.to(1)

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.from(0).to(1)

This is really useful when working with database changes or changes to objects. The matcher is change(), which takes a block and accepts the from(), to() or by() modifiers. [18]

====Errors====
field = CricketGround.new(:players => 11)
lambda {
field.remove(:players, 15)
}.should raise_error(NotEnoughPlayers,“attempted to remove more players than there is on cricket stadium”)

Useful when needed to check for Exceptions. The matcher is raise_error and takes an ExceptionObject and/or a String/Regexp.

====Throw====
speech = Speech.new(:seats => 100)
100.times { speech.register Person.new }
lambda {
speech.register Person.new
}.should throw_symbol(:speech_full, 100)

When dealing with “errors that are not really exceptions”, you use catch and throw. Rspec can check if a throw has been called by using the throw_symbol matcher. It accepts 0,1 or 2 arguments. The first argument needs to be a Symbol and the second can be any Object that is thrown along.

===Predicate Matchers===
A Ruby predicate method is a method that ends with a “?” and returns a boolean value, like string.empty? or regexp.match? methods. Instead of writing:
a_string.empty?.should == true
We can write using RSpec:
a_string.should be_empty

When using a be_something matcher, RSpec removes the “be_”, appends a “?” and calls the resulting method in the receiver. A very common construct of this method is be_true, which checks if the receiver is true (any object except false or nil) or false (false or nil).

===Check Ownership===
Sometimes you will want to check something the object owns and not the object itself.

====The have_something() method====
security_access.has_key?(:id).should == true
is the same as
security_access.should have_key(:id)

RSpec uses method_missing to convert anything that begins with have_something to has_something? and performs the checking.

====The have() method====
field.players.select {|p| p.team == home_team }.length.should == 9
is the same as
home_team.should have(9).players_on(field)

As have() does not respond to players_on(), it delegates to the receiver (home_team). It encourages the home_team object to have useful methods like players_on. 
You can get a NoMethodError if the players_on method doesn´t exist, you can get another NoMethodError if the result of the players_on method doesn´t respond to size() or length() and if the size of the collection doesn´t match the expected size, you will get a failed expectation. [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/]

===Checking Collections Themselves===
Sometimes we create expectations about a collection itself and not about an owned collection. RSpec lets us use the have() method to express this as well, as in:
basket_collection.should have(10).items
items is just providing some meaning to the expectation.

====Strings====
Strings are not collections by definition but they respond to a lot of methods that collections do, like length() and size(). This allow us to use have() to expect a string of a specific length.
“apple”.should have(5).characters
characters is just providing meaning to the expectation as well.

====Have() modifiers for precision====
The have() method has some relatives that allow us to check for upper and lower conditions.

work.should have_exactly(8).hours
classroom.should have_at_most(100).people
bag.should have_at_least(5).items

===Operator Expressions===
There may be sometimes when you want to expect a value to be not an exact amount but something like greater than or less than. RSpec allows you to do this by using the regular operators from Ruby!

number.should == 3
number.should be >= 2
number.should be <= 4
number should be > 0

=References=

# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Programming & Unit Testing]. en.wikibooks.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Ruby Test::Unit]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Ruby Assertions]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html Shoulda Explained]. pragprog.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavior Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://www.springerlink.com/content/978-3-540-22839-4/ Proceedings of Extreme Programming and Agile Methods Conference] Carmen Zannier, Hakan Erdogmus and Lowell Lindstrom. Extreme Programming and Agile Methods - XP/Agile Universe 2004. 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, August 15-18, 2004.
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false Domain-driven design: tackling complexity in the heart of software]. By Eric Evans. books.google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Domain-driven_design Domain Driven Design]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false Test-driven development: by example]. By Kent Beck. books. google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://blog.davidchelimsky.net/ David Chelimsky Blog]. davidchelimsky.net. Retrieved Sep 17, 2010.
# [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/ Understanding RSpec Stories - A Tutorial]. emson.co.uk. Retrieved Sep 17, 2010.
# [http://blog.dannorth.net/2007/06/17/introducing-rbehave/ rbehave]. dannorth.net. Retrieved Sep 17, 2010.
# [http://www.ruby-lang.org Ruby Website]. ruby-lang.org. Retrieved Sep 17, 2010.
# [http://www.pragprog.com/titles/achbd/the-rspec-book RSpec Book]. pragprog.com. Retrieved Sep 17, 2010.
# [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/ RSpec - Expectations]. wordpress.com. Retrieved Sep 17, 2010.

CSC/ECE 517 Fall 2010/ch1 1f vn

2010-09-18T01:47:43Z

Thatvamasi: /* Example */

='''Unit-Testing Frameworks for Ruby'''=

This wiki-page serves as a knowledge source for understanding the different Unit-Testing Frameworks available for Ruby. 

__TOC__

=Introduction=
Unit testing is a method by which we can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written. [http://en.wikipedia.org/wiki/Unit_testing] It helps to identify errors in the program even without running the entire program. It also helps to do regressing testing to identify buggy code additions in the future. Unit testing frameworks provides us with constructs which simplifies the process of unit testing. Using a standard unit test framework helps other developers to add test cases easily. [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing] This chapter walks through three different unit testing frameworks available for Ruby and explains how to use them with examples. The three commonly used unit testing frameworks for ruby are

# Test::Unit
# Shoulda
# RSpec

=Test::Unit=

Now we shall consider Test::Unit framework

==Background==
Ruby comes with an in-built, ready to use unit testing framework called Test::Unit. It is a XUnit type framework and typically have a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests themselves are bundled separately in a test class from the code it is testing.

==Test Fixture==
Test fixture represents the initial environment setup(eg. initialization data) and/or the expected outcome of the tests for that environment. This is typically done in the setup() and teardown() methods and it helps to separate test initialization and cleanup from the actual tests. It also helps to reuse the same fixture for more than one tests.[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html]

For example, consider a method prime_check(num) which takes an integer number as input and outputs whether it is prime number or not. In order to unit test this method we can create the following fixture containing a 2-dimensional array with a number and the expected output of whether it is prime or not.

def setup
@NUMBERS = [[3,true], [4,false], [7,true], [10,false]]
end

==Assertions==
The core part of test::unit framework is the ability to assert a statement of expected outcome. If an assert statement is correct then the test will proceed, otherwise the test will fail. This feature helps us to verify the method under test with different types of inputs and track the results. Test::unit provides a bunch of assert methods for this purpose:

{| border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

For the full list of assertion methods provided by test::unit refer to test::unit assertions. [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html]

==Example==
The test case class BinarySearchTest subclasses the Test::Unit::TestCase class and overrides setup and teardown methods. The test methods should start with 'test_' prefix. This helps in isolating the test methods from the helper methods if any. The Test::Unit::TestCase class takes care of making the test methods into tests, wrapping them into a suite and running the individual tests. The test results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

def setup
@input_array = [1,2,3,4,5] #The test fixture is initialized
end

def test_success_left_half
assert_equal(binary_search(@input_array,1),true) #tests if the element present in left half of the array is found
assert_equal(binary_search(@input_array,2),true)
end

def test_success_right_half
assert_equal(binary_search(@input_array,5),true) #tests if the element present in the right half of the array is found
assert_equal(binary_search(@input_array,4),true)
end

def test_success_middle #tests if the element present in the middle of the array is found
assert_equal(binary_search(@input_array,3),true)
end

def test_failure
assert_equal(binary_search(@input_array,6),false) #tests if an element not present in the array is not found
end

def teardown
#nothing to do here
end

end

Here we have four test methods testing different logical paths of the binary search algorithm. Each test method can have one or more assert statements to test whether conditions are correct in each situation. To run the tests we simply have to run the file binary_search_test.rb and the output is as follows:

Loaded suite binarysearch
Started
F...
Finished in 0.372 seconds.

1) Failure:
test_failure(BinarySearchTest) [binarysearch.rb:25]:
<true> expected but was
<false>.

4 tests, 6 assertions, 1 failures, 0 errors

The results show that the last test case test_failure, testing the negative scenario is failing. The reason is because the assert statement is expecting false when number 6, which not present in the array is passed. But the binary_search method is returning true.

==Test Suite==
Sometimes it is useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose. The below example demonstrates how to bundle binary and sequential test case classes into a single search test suite.

require 'test/unit/testsuite'
require 'binary_search_test'
require 'sequential_search_test'

class Search_Tests
def self.suite
suite = Test::Unit::TestSuite.new
suite << BinarySearchTest.suite
suite << SequentialSearchTest.suite
return suite
end
end
Test::Unit::UI::Console::TestRunner.run(Search_Tests)

=Shoulda=

==Background==
One of the downsides of Test::Unit is we end up writing lots of code in order to test the actual code which is sometimes not easy to understand. Shoulda is a library that allows us to write better and more understandable tests for ruby application. Shoulda is not a testing framework by itself. It extends the Test::Unit framework with the idea of context. We can mix Test::Unit test cases with Shoulda test cases. Shoulda allows us to provide context to the tests so that we can group the tests according to a specific feature or scenario. [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html]

==Example==
require 'shoulda'
require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

context "Input array of size 5" do

def setup
@input_array = [1,2,3,4,5]
end

should "have the number in the left half of the array" do #tests if the element present in left half of the array is found
assert_equal(binary_search(@input_array,1),true)
assert_equal(binary_search(@input_array,2),true)
end

should "have the number in the right half of the array" do #tests if the element present in right half of the array is found
assert_equal(binary_search(@input_array,5),true)
assert_equal(binary_search(@input_array,4),true)
end

should "have the number in the middle of the array" do #tests if the element present in middle of the array is found
assert_equal(binary_search(@input_array,3),true)
end

should "not have the number in the array" do #tests if the element not present in the array is not found
assert_equal(binary_search(@input_array,6),false)
end

def teardown
#nothing to do here
end
end

context "Input array of size 1" do

def setup
@input_array = [1]
end

should "have the number in the array" do
assert_equal(binary_search(@input_array,1),true) #tests if an element is found in the single element array
end

should "not have the number in the array" do # tests if an element is not found in the single element array
assert_equal(binary_search(@input_array,2),true)
end

def teardown
#nothing to do here
end
end
end

Notice that we are still sub-classing the Test::Unit::TestCase class. In this example we have two contexts one for input array of size 5 and the other for input array of size 1. Each context has its own environment of setup/teardown methods. We can also create nested contexts - the outer setup gets run before the execution of each of the inner contexts. And the setup in the inner contexts gets run when running that context. Each should construct is converted into individual test methods and are run. If a test case fails we will get a better description of what that test case is doing from the should description.

=RSpec=

Now let us consider about RSpec Testing Framework in detail.

==Background==

Behaviour Driven Development (BDD) [http://en.wikipedia.org/wiki/Behavior_Driven_Development] is an Agile development process [http://en.wikipedia.org/wiki/Agile_software_development] that comprises aspects of Acceptance Test Driven Planning [http://www.springerlink.com/content/978-3-540-22839-4/] [http://en.wikipedia.org/wiki/Acceptance_testing], Domain Driven Design [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Domain-driven_design] and Test Driven Development (TDD). [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Test-driven_development] RSpec is a Behavioural Driven Development (BDD) tool aimed at Test Driven Development, originally created by Dave Astels and Steven Baker. However David Chelimsky [http://blog.davidchelimsky.net/] is really the gatekeeper of the RSpec project. [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]

Traditionally we use Unit Test frameworks like JUnit, NUnit or RUnit for writing Test cases. We spend a lot of time writing tests that test every unit of code in our software system. Instead we can shift our focus from Unit testing to Behaviour testing or Behaviour Driven Development (BDD) using RSpec. By focusing on the behaviour of the system it helps clarify in our minds what the system should actually be doing. It also helps us to perform more ‘useful’ tests. Useful tests, cover what the system should be doing and build in enough redundancy so that it should be easy to refactor our code without having to re-write every test. 

RSpec is really two projects merged into one. The RSpec project pages describes these merged projects as:

# application level behaviour described by a Story Framework 
# object level behaviour described by a Spec Framework 

Dan North created rbehave [http://blog.dannorth.net/2007/06/17/introducing-rbehave/] which is the Story Framework and David Chelimsky created the Spec Framework. By encompassing two frameworks RSpec equips a programmer with a thorough set of testing tools, allowing you to think about your software problem from a number of perspectives.

==Prerequisites==

The prerequisites are

# Ruby 1.8.4 or later
# RSpec Gem (latest)

To install Ruby, please visit official Ruby Website [http://www.ruby-lang.org/] 
To install RSpec, open a command shell, go to /bin folder in Ruby directory and type 
> gem install rspec

==Terms & Definitions==

Here are some terms which are used frequently while working with RSpec. [http://www.pragprog.com/titles/achbd/the-rspec-book/ ]

# subject code - The code whose behavior is specified using RSpec
# expectation - The expected behavior of subject code is expressed using expectation (Similar to 'Assertions' statements used in Test::Unit or other tools in other languages)
# code example - An executable example containing the subject code and the expectations (Similar to 'Test Method' terminology used elsewhere)
# example group - A group of code examples (Similar to 'Test Case' terminology used elsewhere)
# spec file - A file which contains one or more example groups

==Example==

Let us go through an example to be clear on the usage of RSpec.

require 'binarysearch'

describe BinarySearchTest do
before(:all) do
@input_array = [1, 2, 3, 4, 5] # The Input Array
end

after(:all) do
# do nothing here
end

it "should be in the left-half of the array" do # Test case for element to be present in left-half of given array
bst = BinarySearch.new
bst.should be_binary_search(1)
end

it "should be in the right-half of the array" do # Test case for element to be present in right-half of given array
bst = BinarySearch.new
bst.should be_binary_search(5)
end

it "should be in the middle of the array" do # Test case for element to be present in the middle of given array
bst = BinarySearch.new
bst.should be_binary_search(3)
end

it "should not be in the array"
end

Here it is assumed that the method binary_search will return true/false based on whether the provided value exists in the array or not. It should produce the following output.

BinarySearchTest
- should be in the left-half of the array
- should be in the right-half of the array
- should be in the middle of the array
- should not be in the array (PENDING: Not Yet Implemented)

Pending:
BinaryTestSearch should not be in the array (Not Yet Implemented)
Called from binarysearch.rb:22

Finished in 0.006682 seconds

4 examples, 0 failures, 1 pending

====describe() method====

The describe() method can take an arbitrary number of arguments and a block and returns a sub-class of Spec::Example::ExampleGroup. We generally use only one or two arguments which is used to describe the behavior. The first argument can be a reference to a Class or module or a string. The second argument is optional and should be a string when used.

====it() method====

Similar to the describe() method, the it() method takes a single String, an optional Hash and an optional block. The String expression within the it() should be such that it informs the behavior of the code within the block.

==Expectations in RSpec==

There are two methods available for checking expectations: should() and should_not(). Both the methods accept either an expression matcher or a Ruby expression using a specific subset of Ruby operators. An expression matcher is an objects that matches an expression.

===Built-in Matchers===

There are several matchers that can be used with should and should_not, which are divided into well-separated categories.
====Equality====
subject.should == ece517
subject.should === ece517
subject.should eql(subject)
subject.should equal(subject)

The == method is used to express equivalence and equal is used when you want the receiver and the argument to be the same object. Instead of using !=, you should use the should_not method!

====Floating Point Calculations====
piValue.should be_close(3.14, 0.001593)

Sometimes the values generated might be correct upto some fixed decimal positions, after that they may have slight variations. To avoid the test beings failed, we provide the (value, delta) to be_close method which passes the test if the obtained value lies within the range (value+delta).

====Regular Expressions====
resultExpression.should match(/this regular expression/)
resultExpression.should =~ /this regular expression/

This can be very useful when dealing with multiple-line expectations, instead of using the open file technique to compare contents.

====Changes====
lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.to(1)

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.from(0).to(1)

This is really useful when working with database changes or changes to objects. The matcher is change(), which takes a block and accepts the from(), to() or by() modifiers. [18]

====Errors====
field = CricketGround.new(:players => 11)
lambda {
field.remove(:players, 15)
}.should raise_error(NotEnoughPlayers,“attempted to remove more players than there is on cricket stadium”)

Useful when needed to check for Exceptions. The matcher is raise_error and takes an ExceptionObject and/or a String/Regexp.

====Throw====
speech = Speech.new(:seats => 100)
100.times { speech.register Person.new }
lambda {
speech.register Person.new
}.should throw_symbol(:speech_full, 100)

When dealing with “errors that are not really exceptions”, you use catch and throw. Rspec can check if a throw has been called by using the throw_symbol matcher. It accepts 0,1 or 2 arguments. The first argument needs to be a Symbol and the second can be any Object that is thrown along.

===Predicate Matchers===
A Ruby predicate method is a method that ends with a “?” and returns a boolean value, like string.empty? or regexp.match? methods. Instead of writing:
a_string.empty?.should == true
We can write using RSpec:
a_string.should be_empty

When using a be_something matcher, RSpec removes the “be_”, appends a “?” and calls the resulting method in the receiver. A very common construct of this method is be_true, which checks if the receiver is true (any object except false or nil) or false (false or nil).

===Check Ownership===
Sometimes you will want to check something the object owns and not the object itself.

====The have_something() method====
security_access.has_key?(:id).should == true
is the same as
security_access.should have_key(:id)

RSpec uses method_missing to convert anything that begins with have_something to has_something? and performs the checking.

====The have() method====
field.players.select {|p| p.team == home_team }.length.should == 9
is the same as
home_team.should have(9).players_on(field)

As have() does not respond to players_on(), it delegates to the receiver (home_team). It encourages the home_team object to have useful methods like players_on. 
You can get a NoMethodError if the players_on method doesn´t exist, you can get another NoMethodError if the result of the players_on method doesn´t respond to size() or length() and if the size of the collection doesn´t match the expected size, you will get a failed expectation. [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/]

===Checking Collections Themselves===
Sometimes we create expectations about a collection itself and not about an owned collection. RSpec lets us use the have() method to express this as well, as in:
basket_collection.should have(10).items
items is just providing some meaning to the expectation.

====Strings====
Strings are not collections by definition but they respond to a lot of methods that collections do, like length() and size(). This allow us to use have() to expect a string of a specific length.
“apple”.should have(5).characters
characters is just providing meaning to the expectation as well.

====Have() modifiers for precision====
The have() method has some relatives that allow us to check for upper and lower conditions.

work.should have_exactly(8).hours
classroom.should have_at_most(100).people
bag.should have_at_least(5).items

===Operator Expressions===
There may be sometimes when you want to expect a value to be not an exact amount but something like greater than or less than. RSpec allows you to do this by using the regular operators from Ruby!

number.should == 3
number.should be >= 2
number.should be <= 4
number should be > 0

=References=

# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Programming & Unit Testing]. en.wikibooks.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Ruby Test::Unit]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Ruby Assertions]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html Shoulda Explained]. pragprog.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavior Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://www.springerlink.com/content/978-3-540-22839-4/ Proceedings of Extreme Programming and Agile Methods Conference] Carmen Zannier, Hakan Erdogmus and Lowell Lindstrom. Extreme Programming and Agile Methods - XP/Agile Universe 2004. 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, August 15-18, 2004.
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false Domain-driven design: tackling complexity in the heart of software]. By Eric Evans. books.google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Domain-driven_design Domain Driven Design]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false Test-driven development: by example]. By Kent Beck. books. google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://blog.davidchelimsky.net/ David Chelimsky Blog]. davidchelimsky.net. Retrieved Sep 17, 2010.
# [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/ Understanding RSpec Stories - A Tutorial]. emson.co.uk. Retrieved Sep 17, 2010.
# [http://blog.dannorth.net/2007/06/17/introducing-rbehave/ rbehave]. dannorth.net. Retrieved Sep 17, 2010.
# [http://www.ruby-lang.org Ruby Website]. ruby-lang.org. Retrieved Sep 17, 2010.
# [http://www.pragprog.com/titles/achbd/the-rspec-book RSpec Book]. pragprog.com. Retrieved Sep 17, 2010.
# [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/ RSpec - Expectations]. wordpress.com. Retrieved Sep 17, 2010.

CSC/ECE 517 Fall 2010/ch1 1f vn

2010-09-18T01:15:48Z

Thatvamasi: /* References */

='''Unit-Testing Frameworks for Ruby'''=

This wiki-page serves as a knowledge source for understanding the different Unit-Testing Frameworks available for Ruby. 

__TOC__

=Introduction=
Unit testing is a method by which we can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written. [http://en.wikipedia.org/wiki/Unit_testing] It helps to identify errors in the program even without running the entire program. It also helps to do regressing testing to identify buggy code additions in the future. Unit testing frameworks provides us with constructs which simplifies the process of unit testing. Using a standard unit test framework helps other developers to add test cases easily. [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing] This chapter walks through three different unit testing frameworks available for Ruby and explains how to use them with examples. The three commonly used unit testing frameworks for ruby are

# Test::Unit
# Shoulda
# RSpec

=Test::Unit=

==Background==
Ruby comes with an in-built, ready to use unit testing framework called Test::Unit. It is a XUnit type framework and typically have a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests themselves are bundled separately in a test class from the code it is testing.

==Test Fixture==
Test fixture represents the initial environment setup(eg. initialization data) and/or the expected outcome of the tests for that environment. This is typically done in the setup() and teardown() methods and it helps to separate test initialization and cleanup from the actual tests. It also helps to reuse the same fixture for more than one tests.[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html]

For example, consider a method prime_check(num) which takes an integer number as input and outputs whether it is prime number or not. In order to unit test this method we can create the following fixture containing a 2-dimensional array with a number and the expected output of whether it is prime or not.

def setup
@NUMBERS = [[3,true], [4,false], [7,true], [10,false]]
end

==Assertions==
The core part of test::unit framework is the ability to assert a statement of expected outcome. If an assert statement is correct then the test will proceed, otherwise the test will fail. This feature helps us to verify the method under test with different types of inputs and track the results. Test::unit provides a bunch of assert methods for this purpose:

{| border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

For the full list of assertion methods provided by test::unit refer to test::unit assertions. [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html]

==Example==
The test case class BinarySearchTest subclasses the Test::Unit::TestCase class and overrides setup and teardown methods. The test methods should start with 'test_' prefix. This helps in isolating the test methods from the helper methods if any. The Test::Unit::TestCase class takes care of making the test methods into tests, wrapping them into a suite and running the individual tests. The test results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

def setup
@input_array = [1,2,3,4,5]
end

def test_success_left_half
assert_equal(binary_search(@input_array,1),true)
assert_equal(binary_search(@input_array,2),true)
end

def test_success_right_half
assert_equal(binary_search(@input_array,5),true)
assert_equal(binary_search(@input_array,4),true)
end

def test_success_middle
assert_equal(binary_search(@input_array,3),true)
end

def test_failure
assert_equal(binary_search(@input_array,6),false)
end

def teardown
#nothing to do here
end

end

Here we have four test methods testing different logical paths of the binary search algorithm. Each test method can have one or more assert statements to test whether conditions are correct in each situation. To run the tests we simply have to run the file binary_search_test.rb and the output is as follows:

Loaded suite binarysearch
Started
F...
Finished in 0.372 seconds.

1) Failure:
test_failure(BinarySearchTest) [binarysearch.rb:25]:
<true> expected but was
<false>.

4 tests, 6 assertions, 1 failures, 0 errors

The results show that the last test case test_failure, testing the negative scenario is failing. The reason is because the assert statement is expecting false when number 6, which not present in the array is passed. But the binary_search method is returning true.

==Test Suite==
Sometimes it is useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose. The below example demonstrates how to bundle binary and sequential test case classes into a single search test suite.

require 'test/unit/testsuite'
require 'binary_search_test'
require 'sequential_search_test'

class Search_Tests
def self.suite
suite = Test::Unit::TestSuite.new
suite << BinarySearchTest.suite
suite << SequentialSearchTest.suite
return suite
end
end
Test::Unit::UI::Console::TestRunner.run(Search_Tests)

=Shoulda=

==Background==
One of the downsides of Test::Unit is we end up writing lots of code in order to test the actual code which is sometimes not easy to understand. Shoulda is a library that allows us to write better and more understandable tests for ruby application. Shoulda is not a testing framework by itself. It extends the Test::Unit framework with the idea of context. We can mix Test::Unit test cases with Shoulda test cases. Shoulda allows us to provide context to the tests so that we can group the tests according to a specific feature or scenario. [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html]

==Example==
require 'shoulda'
require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

context "Input array of size 5" do

def setup
@input_array = [1,2,3,4,5]
end

should "have the number in the left half of the array" do
assert_equal(binary_search(@input_array,1),true)
assert_equal(binary_search(@input_array,2),true)
end

should "have the number in the right half of the array" do
assert_equal(binary_search(@input_array,5),true)
assert_equal(binary_search(@input_array,4),true)
end

should "have the number in the middle of the array" do
assert_equal(binary_search(@input_array,3),true)
end

should "not have the number in the array" do
assert_equal(binary_search(@input_array,6),false)
end

def teardown
#nothing to do here
end
end

context "Input array of size 1" do

def setup
@input_array = [1]
end

should "have the number in the array" do
assert_equal(binary_search(@input_array,1),true)
end

should "not have the number in the array" do
assert_equal(binary_search(@input_array,2),true)
end

def teardown
#nothing to do here
end
end
end

Notice that we are still sub-classing the Test::Unit::TestCase class. In this example we have two contexts one for input array of size 5 and the other for input array of size 1. Each context has its own environment of setup/teardown methods. We can also create nested contexts - the outer setup gets run before the execution of each of the inner contexts. And the setup in the inner contexts gets run when running that context. Each should construct is converted into individual test methods and are run. If a test case fails we will get a better description of what that test case is doing from the should description.

=RSpec=

Now let us consider about RSpec Testing Framework in detail.

==Background==

Behaviour Driven Development (BDD) [http://en.wikipedia.org/wiki/Behavior_Driven_Development] is an Agile development process [http://en.wikipedia.org/wiki/Agile_software_development] that comprises aspects of Acceptance Test Driven Planning [http://www.springerlink.com/content/978-3-540-22839-4/] [http://en.wikipedia.org/wiki/Acceptance_testing], Domain Driven Design [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Domain-driven_design] and Test Driven Development (TDD). [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Test-driven_development] RSpec is a Behavioural Driven Development (BDD) tool aimed at Test Driven Development, originally created by Dave Astels and Steven Baker. However David Chelimsky [http://blog.davidchelimsky.net/] is really the gatekeeper of the RSpec project. [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]

Traditionally we use Unit Test frameworks like JUnit, NUnit or RUnit for writing Test cases. We spend a lot of time writing tests that test every unit of code in our software system. Instead we can shift our focus from Unit testing to Behaviour testing or Behaviour Driven Development (BDD) using RSpec. By focusing on the behaviour of the system it helps clarify in our minds what the system should actually be doing. It also helps us to perform more ‘useful’ tests. Useful tests, cover what the system should be doing and build in enough redundancy so that it should be easy to refactor our code without having to re-write every test. 

RSpec is really two projects merged into one. The RSpec project pages describes these merged projects as:

# application level behaviour described by a Story Framework 
# object level behaviour described by a Spec Framework 

Dan North created rbehave [http://blog.dannorth.net/2007/06/17/introducing-rbehave/] which is the Story Framework and David Chelimsky created the Spec Framework. By encompassing two frameworks RSpec equips a programmer with a thorough set of testing tools, allowing you to think about your software problem from a number of perspectives.

==Prerequisites==

The prerequisites are

# Ruby 1.8.4 or later
# RSpec Gem (latest)

To install Ruby, please visit official Ruby Website [http://www.ruby-lang.org/] 
To install RSpec, open a command shell, go to /bin folder in Ruby directory and type 
> gem install rspec

==Terms & Definitions==

Here are some terms which are used frequently while working with RSpec. [http://www.pragprog.com/titles/achbd/the-rspec-book/ ]

# subject code - The code whose behavior is specified using RSpec
# expectation - The expected behavior of subject code is expressed using expectation (Similar to 'Assertions' statements used in Test::Unit or other tools in other languages)
# code example - An executable example containing the subject code and the expectations (Similar to 'Test Method' terminology used elsewhere)
# example group - A group of code examples (Similar to 'Test Case' terminology used elsewhere)
# spec file - A file which contains one or more example groups

==Example==

Let us go through an example to be clear on the usage of RSpec.

require 'binarysearch'

describe BinarySearchTest do
before(:all) do
@input_array = [1, 2, 3, 4, 5] # The Input Array
end

after(:all) do
# do nothing here
end

it "should be in the left-half of the array" do # Test case for element to be present in left-half of given array
bst = BinarySearch.new
bst.should be_binary_search(1)
end

it "should be in the right-half of the array" do # Test case for element to be present in right-half of given array
bst = BinarySearch.new
bst.should be_binary_search(5)
end

it "should be in the middle of the array" do # Test case for element to be present in the middle of given array
bst = BinarySearch.new
bst.should be_binary_search(3)
end

it "should not be in the array" do # Test case for element NOT to be present in given array
bst = BinarySearch.new
bst.should_not be_binary_search(7)
end
end

Here it is assumed that the method binary_search will return true/false based on whether the provided value exists in the array or not.

====describe() method====

The describe() method can take an arbitrary number of arguments and a block and returns a sub-class of Spec::Example::ExampleGroup. We generally use only one or two arguments which is used to describe the behavior. The first argument can be a reference to a Class or module or a string. The second argument is optional and should be a string when used.

====it() method====

Similar to the describe() method, the it() method takes a single String, an optional Hash and an optional block. The String expression within the it() should be such that it informs the behavior of the code within the block.

==Expectations in RSpec==

There are two methods available for checking expectations: should() and should_not(). Both the methods accept either an expression matcher or a Ruby expression using a specific subset of Ruby operators. An expression matcher is an objects that matches an expression.

===Built-in Matchers===

There are several matchers that can be used with should and should_not, which are divided into well-separated categories.
====Equality====
subject.should == ece517
subject.should === ece517
subject.should eql(subject)
subject.should equal(subject)

The == method is used to express equivalence and equal is used when you want the receiver and the argument to be the same object. Instead of using !=, you should use the should_not method!

====Floating Point Calculations====
piValue.should be_close(3.14, 0.001593)

Sometimes the values generated might be correct upto some fixed decimal positions, after that they may have slight variations. To avoid the test beings failed, we provide the (value, delta) to be_close method which passes the test if the obtained value lies within the range (value+delta).

====Regular Expressions====
resultExpression.should match(/this regular expression/)
resultExpression.should =~ /this regular expression/

This can be very useful when dealing with multiple-line expectations, instead of using the open file technique to compare contents.

====Changes====
lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.to(1)

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.from(0).to(1)

This is really useful when working with database changes or changes to objects. The matcher is change(), which takes a block and accepts the from(), to() or by() modifiers. [18]

====Errors====
field = CricketGround.new(:players => 11)
lambda {
field.remove(:players, 15)
}.should raise_error(NotEnoughPlayers,“attempted to remove more players than there is on cricket stadium”)

Useful when needed to check for Exceptions. The matcher is raise_error and takes an ExceptionObject and/or a String/Regexp.

====Throw====
speech = Speech.new(:seats => 100)
100.times { speech.register Person.new }
lambda {
speech.register Person.new
}.should throw_symbol(:speech_full, 100)

When dealing with “errors that are not really exceptions”, you use catch and throw. Rspec can check if a throw has been called by using the throw_symbol matcher. It accepts 0,1 or 2 arguments. The first argument needs to be a Symbol and the second can be any Object that is thrown along.

===Predicate Matchers===
A Ruby predicate method is a method that ends with a “?” and returns a boolean value, like string.empty? or regexp.match? methods. Instead of writing:
a_string.empty?.should == true
We can write using RSpec:
a_string.should be_empty

When using a be_something matcher, RSpec removes the “be_”, appends a “?” and calls the resulting method in the receiver. A very common construct of this method is be_true, which checks if the receiver is true (any object except false or nil) or false (false or nil).

===Check Ownership===
Sometimes you will want to check something the object owns and not the object itself.

====The have_something() method====
security_access.has_key?(:id).should == true
is the same as
security_access.should have_key(:id)

RSpec uses method_missing to convert anything that begins with have_something to has_something? and performs the checking.

====The have() method====
field.players.select {|p| p.team == home_team }.length.should == 9
is the same as
home_team.should have(9).players_on(field)

As have() does not respond to players_on(), it delegates to the receiver (home_team). It encourages the home_team object to have useful methods like players_on. 
You can get a NoMethodError if the players_on method doesn´t exist, you can get another NoMethodError if the result of the players_on method doesn´t respond to size() or length() and if the size of the collection doesn´t match the expected size, you will get a failed expectation. [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/]

===Checking Collections Themselves===
Sometimes we create expectations about a collection itself and not about an owned collection. RSpec lets us use the have() method to express this as well, as in:
basket_collection.should have(10).items
items is just providing some meaning to the expectation.

====Strings====
Strings are not collections by definition but they respond to a lot of methods that collections do, like length() and size(). This allow us to use have() to expect a string of a specific length.
“apple”.should have(5).characters
characters is just providing meaning to the expectation as well.

====Have() modifiers for precision====
The have() method has some relatives that allow us to check for upper and lower conditions.

work.should have_exactly(8).hours
classroom.should have_at_most(100).people
bag.should have_at_least(5).items

===Operator Expressions===
There may be sometimes when you want to expect a value to be not an exact amount but something like greater than or less than. RSpec allows you to do this by using the regular operators from Ruby!

number.should == 3
number.should be >= 2
number.should be <= 4
number should be > 0

=References=

# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Programming & Unit Testing]. en.wikibooks.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Ruby Test::Unit]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Ruby Assertions]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html Shoulda Explained]. pragprog.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavior Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://www.springerlink.com/content/978-3-540-22839-4/ Proceedings of Extreme Programming and Agile Methods Conference] Carmen Zannier, Hakan Erdogmus and Lowell Lindstrom. Extreme Programming and Agile Methods - XP/Agile Universe 2004. 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, August 15-18, 2004.
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false Domain-driven design: tackling complexity in the heart of software]. By Eric Evans. books.google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Domain-driven_design Domain Driven Design]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false Test-driven development: by example]. By Kent Beck. books. google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://blog.davidchelimsky.net/ David Chelimsky Blog]. davidchelimsky.net. Retrieved Sep 17, 2010.
# [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/ Understanding RSpec Stories - A Tutorial]. emson.co.uk. Retrieved Sep 17, 2010.
# [http://blog.dannorth.net/2007/06/17/introducing-rbehave/ rbehave]. dannorth.net. Retrieved Sep 17, 2010.
# [http://www.ruby-lang.org Ruby Website]. ruby-lang.org. Retrieved Sep 17, 2010.
# [http://www.pragprog.com/titles/achbd/the-rspec-book RSpec Book]. pragprog.com. Retrieved Sep 17, 2010.
# [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/ RSpec - Expectations]. wordpress.com. Retrieved Sep 17, 2010.

CSC/ECE 517 Fall 2010/ch1 1f vn

2010-09-18T01:15:23Z

Thatvamasi: /* References */

='''Unit-Testing Frameworks for Ruby'''=

This wiki-page serves as a knowledge source for understanding the different Unit-Testing Frameworks available for Ruby. 

__TOC__

=Introduction=
Unit testing is a method by which we can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written. [http://en.wikipedia.org/wiki/Unit_testing] It helps to identify errors in the program even without running the entire program. It also helps to do regressing testing to identify buggy code additions in the future. Unit testing frameworks provides us with constructs which simplifies the process of unit testing. Using a standard unit test framework helps other developers to add test cases easily. [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing] This chapter walks through three different unit testing frameworks available for Ruby and explains how to use them with examples. The three commonly used unit testing frameworks for ruby are

# Test::Unit
# Shoulda
# RSpec

=Test::Unit=

==Background==
Ruby comes with an in-built, ready to use unit testing framework called Test::Unit. It is a XUnit type framework and typically have a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests themselves are bundled separately in a test class from the code it is testing.

==Test Fixture==
Test fixture represents the initial environment setup(eg. initialization data) and/or the expected outcome of the tests for that environment. This is typically done in the setup() and teardown() methods and it helps to separate test initialization and cleanup from the actual tests. It also helps to reuse the same fixture for more than one tests.[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html]

For example, consider a method prime_check(num) which takes an integer number as input and outputs whether it is prime number or not. In order to unit test this method we can create the following fixture containing a 2-dimensional array with a number and the expected output of whether it is prime or not.

def setup
@NUMBERS = [[3,true], [4,false], [7,true], [10,false]]
end

==Assertions==
The core part of test::unit framework is the ability to assert a statement of expected outcome. If an assert statement is correct then the test will proceed, otherwise the test will fail. This feature helps us to verify the method under test with different types of inputs and track the results. Test::unit provides a bunch of assert methods for this purpose:

{| border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

For the full list of assertion methods provided by test::unit refer to test::unit assertions. [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html]

==Example==
The test case class BinarySearchTest subclasses the Test::Unit::TestCase class and overrides setup and teardown methods. The test methods should start with 'test_' prefix. This helps in isolating the test methods from the helper methods if any. The Test::Unit::TestCase class takes care of making the test methods into tests, wrapping them into a suite and running the individual tests. The test results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

def setup
@input_array = [1,2,3,4,5]
end

def test_success_left_half
assert_equal(binary_search(@input_array,1),true)
assert_equal(binary_search(@input_array,2),true)
end

def test_success_right_half
assert_equal(binary_search(@input_array,5),true)
assert_equal(binary_search(@input_array,4),true)
end

def test_success_middle
assert_equal(binary_search(@input_array,3),true)
end

def test_failure
assert_equal(binary_search(@input_array,6),false)
end

def teardown
#nothing to do here
end

end

Here we have four test methods testing different logical paths of the binary search algorithm. Each test method can have one or more assert statements to test whether conditions are correct in each situation. To run the tests we simply have to run the file binary_search_test.rb and the output is as follows:

Loaded suite binarysearch
Started
F...
Finished in 0.372 seconds.

1) Failure:
test_failure(BinarySearchTest) [binarysearch.rb:25]:
<true> expected but was
<false>.

4 tests, 6 assertions, 1 failures, 0 errors

The results show that the last test case test_failure, testing the negative scenario is failing. The reason is because the assert statement is expecting false when number 6, which not present in the array is passed. But the binary_search method is returning true.

==Test Suite==
Sometimes it is useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose. The below example demonstrates how to bundle binary and sequential test case classes into a single search test suite.

require 'test/unit/testsuite'
require 'binary_search_test'
require 'sequential_search_test'

class Search_Tests
def self.suite
suite = Test::Unit::TestSuite.new
suite << BinarySearchTest.suite
suite << SequentialSearchTest.suite
return suite
end
end
Test::Unit::UI::Console::TestRunner.run(Search_Tests)

=Shoulda=

==Background==
One of the downsides of Test::Unit is we end up writing lots of code in order to test the actual code which is sometimes not easy to understand. Shoulda is a library that allows us to write better and more understandable tests for ruby application. Shoulda is not a testing framework by itself. It extends the Test::Unit framework with the idea of context. We can mix Test::Unit test cases with Shoulda test cases. Shoulda allows us to provide context to the tests so that we can group the tests according to a specific feature or scenario. [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html]

==Example==
require 'shoulda'
require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

context "Input array of size 5" do

def setup
@input_array = [1,2,3,4,5]
end

should "have the number in the left half of the array" do
assert_equal(binary_search(@input_array,1),true)
assert_equal(binary_search(@input_array,2),true)
end

should "have the number in the right half of the array" do
assert_equal(binary_search(@input_array,5),true)
assert_equal(binary_search(@input_array,4),true)
end

should "have the number in the middle of the array" do
assert_equal(binary_search(@input_array,3),true)
end

should "not have the number in the array" do
assert_equal(binary_search(@input_array,6),false)
end

def teardown
#nothing to do here
end
end

context "Input array of size 1" do

def setup
@input_array = [1]
end

should "have the number in the array" do
assert_equal(binary_search(@input_array,1),true)
end

should "not have the number in the array" do
assert_equal(binary_search(@input_array,2),true)
end

def teardown
#nothing to do here
end
end
end

Notice that we are still sub-classing the Test::Unit::TestCase class. In this example we have two contexts one for input array of size 5 and the other for input array of size 1. Each context has its own environment of setup/teardown methods. We can also create nested contexts - the outer setup gets run before the execution of each of the inner contexts. And the setup in the inner contexts gets run when running that context. Each should construct is converted into individual test methods and are run. If a test case fails we will get a better description of what that test case is doing from the should description.

=RSpec=

Now let us consider about RSpec Testing Framework in detail.

==Background==

Behaviour Driven Development (BDD) [http://en.wikipedia.org/wiki/Behavior_Driven_Development] is an Agile development process [http://en.wikipedia.org/wiki/Agile_software_development] that comprises aspects of Acceptance Test Driven Planning [http://www.springerlink.com/content/978-3-540-22839-4/] [http://en.wikipedia.org/wiki/Acceptance_testing], Domain Driven Design [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Domain-driven_design] and Test Driven Development (TDD). [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Test-driven_development] RSpec is a Behavioural Driven Development (BDD) tool aimed at Test Driven Development, originally created by Dave Astels and Steven Baker. However David Chelimsky [http://blog.davidchelimsky.net/] is really the gatekeeper of the RSpec project. [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]

Traditionally we use Unit Test frameworks like JUnit, NUnit or RUnit for writing Test cases. We spend a lot of time writing tests that test every unit of code in our software system. Instead we can shift our focus from Unit testing to Behaviour testing or Behaviour Driven Development (BDD) using RSpec. By focusing on the behaviour of the system it helps clarify in our minds what the system should actually be doing. It also helps us to perform more ‘useful’ tests. Useful tests, cover what the system should be doing and build in enough redundancy so that it should be easy to refactor our code without having to re-write every test. 

RSpec is really two projects merged into one. The RSpec project pages describes these merged projects as:

# application level behaviour described by a Story Framework 
# object level behaviour described by a Spec Framework 

Dan North created rbehave [http://blog.dannorth.net/2007/06/17/introducing-rbehave/] which is the Story Framework and David Chelimsky created the Spec Framework. By encompassing two frameworks RSpec equips a programmer with a thorough set of testing tools, allowing you to think about your software problem from a number of perspectives.

==Prerequisites==

The prerequisites are

# Ruby 1.8.4 or later
# RSpec Gem (latest)

To install Ruby, please visit official Ruby Website [http://www.ruby-lang.org/] 
To install RSpec, open a command shell, go to /bin folder in Ruby directory and type 
> gem install rspec

==Terms & Definitions==

Here are some terms which are used frequently while working with RSpec. [http://www.pragprog.com/titles/achbd/the-rspec-book/ ]

# subject code - The code whose behavior is specified using RSpec
# expectation - The expected behavior of subject code is expressed using expectation (Similar to 'Assertions' statements used in Test::Unit or other tools in other languages)
# code example - An executable example containing the subject code and the expectations (Similar to 'Test Method' terminology used elsewhere)
# example group - A group of code examples (Similar to 'Test Case' terminology used elsewhere)
# spec file - A file which contains one or more example groups

==Example==

Let us go through an example to be clear on the usage of RSpec.

require 'binarysearch'

describe BinarySearchTest do
before(:all) do
@input_array = [1, 2, 3, 4, 5] # The Input Array
end

after(:all) do
# do nothing here
end

it "should be in the left-half of the array" do # Test case for element to be present in left-half of given array
bst = BinarySearch.new
bst.should be_binary_search(1)
end

it "should be in the right-half of the array" do # Test case for element to be present in right-half of given array
bst = BinarySearch.new
bst.should be_binary_search(5)
end

it "should be in the middle of the array" do # Test case for element to be present in the middle of given array
bst = BinarySearch.new
bst.should be_binary_search(3)
end

it "should not be in the array" do # Test case for element NOT to be present in given array
bst = BinarySearch.new
bst.should_not be_binary_search(7)
end
end

Here it is assumed that the method binary_search will return true/false based on whether the provided value exists in the array or not.

====describe() method====

The describe() method can take an arbitrary number of arguments and a block and returns a sub-class of Spec::Example::ExampleGroup. We generally use only one or two arguments which is used to describe the behavior. The first argument can be a reference to a Class or module or a string. The second argument is optional and should be a string when used.

====it() method====

Similar to the describe() method, the it() method takes a single String, an optional Hash and an optional block. The String expression within the it() should be such that it informs the behavior of the code within the block.

==Expectations in RSpec==

There are two methods available for checking expectations: should() and should_not(). Both the methods accept either an expression matcher or a Ruby expression using a specific subset of Ruby operators. An expression matcher is an objects that matches an expression.

===Built-in Matchers===

There are several matchers that can be used with should and should_not, which are divided into well-separated categories.
====Equality====
subject.should == ece517
subject.should === ece517
subject.should eql(subject)
subject.should equal(subject)

The == method is used to express equivalence and equal is used when you want the receiver and the argument to be the same object. Instead of using !=, you should use the should_not method!

====Floating Point Calculations====
piValue.should be_close(3.14, 0.001593)

Sometimes the values generated might be correct upto some fixed decimal positions, after that they may have slight variations. To avoid the test beings failed, we provide the (value, delta) to be_close method which passes the test if the obtained value lies within the range (value+delta).

====Regular Expressions====
resultExpression.should match(/this regular expression/)
resultExpression.should =~ /this regular expression/

This can be very useful when dealing with multiple-line expectations, instead of using the open file technique to compare contents.

====Changes====
lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.to(1)

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.from(0).to(1)

This is really useful when working with database changes or changes to objects. The matcher is change(), which takes a block and accepts the from(), to() or by() modifiers. [18]

====Errors====
field = CricketGround.new(:players => 11)
lambda {
field.remove(:players, 15)
}.should raise_error(NotEnoughPlayers,“attempted to remove more players than there is on cricket stadium”)

Useful when needed to check for Exceptions. The matcher is raise_error and takes an ExceptionObject and/or a String/Regexp.

====Throw====
speech = Speech.new(:seats => 100)
100.times { speech.register Person.new }
lambda {
speech.register Person.new
}.should throw_symbol(:speech_full, 100)

When dealing with “errors that are not really exceptions”, you use catch and throw. Rspec can check if a throw has been called by using the throw_symbol matcher. It accepts 0,1 or 2 arguments. The first argument needs to be a Symbol and the second can be any Object that is thrown along.

===Predicate Matchers===
A Ruby predicate method is a method that ends with a “?” and returns a boolean value, like string.empty? or regexp.match? methods. Instead of writing:
a_string.empty?.should == true
We can write using RSpec:
a_string.should be_empty

When using a be_something matcher, RSpec removes the “be_”, appends a “?” and calls the resulting method in the receiver. A very common construct of this method is be_true, which checks if the receiver is true (any object except false or nil) or false (false or nil).

===Check Ownership===
Sometimes you will want to check something the object owns and not the object itself.

====The have_something() method====
security_access.has_key?(:id).should == true
is the same as
security_access.should have_key(:id)

RSpec uses method_missing to convert anything that begins with have_something to has_something? and performs the checking.

====The have() method====
field.players.select {|p| p.team == home_team }.length.should == 9
is the same as
home_team.should have(9).players_on(field)

As have() does not respond to players_on(), it delegates to the receiver (home_team). It encourages the home_team object to have useful methods like players_on. 
You can get a NoMethodError if the players_on method doesn´t exist, you can get another NoMethodError if the result of the players_on method doesn´t respond to size() or length() and if the size of the collection doesn´t match the expected size, you will get a failed expectation. [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/]

===Checking Collections Themselves===
Sometimes we create expectations about a collection itself and not about an owned collection. RSpec lets us use the have() method to express this as well, as in:
basket_collection.should have(10).items
items is just providing some meaning to the expectation.

====Strings====
Strings are not collections by definition but they respond to a lot of methods that collections do, like length() and size(). This allow us to use have() to expect a string of a specific length.
“apple”.should have(5).characters
characters is just providing meaning to the expectation as well.

====Have() modifiers for precision====
The have() method has some relatives that allow us to check for upper and lower conditions.

work.should have_exactly(8).hours
classroom.should have_at_most(100).people
bag.should have_at_least(5).items

===Operator Expressions===
There may be sometimes when you want to expect a value to be not an exact amount but something like greater than or less than. RSpec allows you to do this by using the regular operators from Ruby!

number.should == 3
number.should be >= 2
number.should be <= 4
number should be > 0

=References=

# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Programming & Unit Testing]. en.wikibooks.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Ruby Test::Unit]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Ruby Assertions]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html Shoulda Explained]. pragprog.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavior Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://www.springerlink.com/content/978-3-540-22839-4/ Proceedings of Extreme Programming and Agile Methods] Carmen Zannier, Hakan Erdogmus and Lowell Lindstrom. Extreme Programming and Agile Methods - XP/Agile Universe 2004. 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, August 15-18, 2004.
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false Domain-driven design: tackling complexity in the heart of software]. By Eric Evans. books.google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Domain-driven_design Domain Driven Design]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false Test-driven development: by example]. By Kent Beck. books. google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://blog.davidchelimsky.net/ David Chelimsky Blog]. davidchelimsky.net. Retrieved Sep 17, 2010.
# [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/ Understanding RSpec Stories - A Tutorial]. emson.co.uk. Retrieved Sep 17, 2010.
# [http://blog.dannorth.net/2007/06/17/introducing-rbehave/ rbehave]. dannorth.net. Retrieved Sep 17, 2010.
# [http://www.ruby-lang.org Ruby Website]. ruby-lang.org. Retrieved Sep 17, 2010.
# [http://www.pragprog.com/titles/achbd/the-rspec-book RSpec Book]. pragprog.com. Retrieved Sep 17, 2010.
# [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/ RSpec - Expectations]. wordpress.com. Retrieved Sep 17, 2010.

CSC/ECE 517 Fall 2010/ch1 1f vn

2010-09-18T01:06:12Z

Thatvamasi: /* The have() method */

='''Unit-Testing Frameworks for Ruby'''=

This wiki-page serves as a knowledge source for understanding the different Unit-Testing Frameworks available for Ruby. 

__TOC__

=Introduction=
Unit testing is a method by which we can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written. [http://en.wikipedia.org/wiki/Unit_testing] It helps to identify errors in the program even without running the entire program. It also helps to do regressing testing to identify buggy code additions in the future. Unit testing frameworks provides us with constructs which simplifies the process of unit testing. Using a standard unit test framework helps other developers to add test cases easily. [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing] This chapter walks through three different unit testing frameworks available for Ruby and explains how to use them with examples. The three commonly used unit testing frameworks for ruby are

# Test::Unit
# Shoulda
# RSpec

=Test::Unit=

==Background==
Ruby comes with an in-built, ready to use unit testing framework called Test::Unit. It is a XUnit type framework and typically have a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests themselves are bundled separately in a test class from the code it is testing.

==Test Fixture==
Test fixture represents the initial environment setup(eg. initialization data) and/or the expected outcome of the tests for that environment. This is typically done in the setup() and teardown() methods and it helps to separate test initialization and cleanup from the actual tests. It also helps to reuse the same fixture for more than one tests.[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html]

For example, consider a method prime_check(num) which takes an integer number as input and outputs whether it is prime number or not. In order to unit test this method we can create the following fixture containing a 2-dimensional array with a number and the expected output of whether it is prime or not.

def setup
@NUMBERS = [[3,true], [4,false], [7,true], [10,false]]
end

==Assertions==
The core part of test::unit framework is the ability to assert a statement of expected outcome. If an assert statement is correct then the test will proceed, otherwise the test will fail. This feature helps us to verify the method under test with different types of inputs and track the results. Test::unit provides a bunch of assert methods for this purpose:

{| border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

For the full list of assertion methods provided by test::unit refer to test::unit assertions. [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html]

==Example==
The test case class BinarySearchTest subclasses the Test::Unit::TestCase class and overrides setup and teardown methods. The test methods should start with 'test_' prefix. This helps in isolating the test methods from the helper methods if any. The Test::Unit::TestCase class takes care of making the test methods into tests, wrapping them into a suite and running the individual tests. The test results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

def setup
@input_array = [1,2,3,4,5]
end

def test_success_left_half
assert_equal(binary_search(@input_array,1),true)
assert_equal(binary_search(@input_array,2),true)
end

def test_success_right_half
assert_equal(binary_search(@input_array,5),true)
assert_equal(binary_search(@input_array,4),true)
end

def test_success_middle
assert_equal(binary_search(@input_array,3),true)
end

def test_failure
assert_equal(binary_search(@input_array,6),false)
end

def teardown
#nothing to do here
end

end

Here we have four test methods testing different logical paths of the binary search algorithm. Each test method can have one or more assert statements to test whether conditions are correct in each situation. To run the tests we simply have to run the file binary_search_test.rb and the output is as follows:

Loaded suite binarysearch
Started
F...
Finished in 0.372 seconds.

1) Failure:
test_failure(BinarySearchTest) [binarysearch.rb:25]:
<true> expected but was
<false>.

4 tests, 6 assertions, 1 failures, 0 errors

The results show that the last test case test_failure, testing the negative scenario is failing. The reason is because the assert statement is expecting false when number 6, which not present in the array is passed. But the binary_search method is returning true.

==Test Suite==
Sometimes it is useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose. The below example demonstrates how to bundle binary and sequential test case classes into a single search test suite.

require 'test/unit/testsuite'
require 'binary_search_test'
require 'sequential_search_test'

class Search_Tests
def self.suite
suite = Test::Unit::TestSuite.new
suite << BinarySearchTest.suite
suite << SequentialSearchTest.suite
return suite
end
end
Test::Unit::UI::Console::TestRunner.run(Search_Tests)

=Shoulda=

==Background==
One of the downsides of Test::Unit is we end up writing lots of code in order to test the actual code which is sometimes not easy to understand. Shoulda is a library that allows us to write better and more understandable tests for ruby application. Shoulda is not a testing framework by itself. It extends the Test::Unit framework with the idea of context. We can mix Test::Unit test cases with Shoulda test cases. Shoulda allows us to provide context to the tests so that we can group the tests according to a specific feature or scenario. [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html]

==Example==
require 'shoulda'
require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

context "Input array of size 5" do

def setup
@input_array = [1,2,3,4,5]
end

should "have the number in the left half of the array" do
assert_equal(binary_search(@input_array,1),true)
assert_equal(binary_search(@input_array,2),true)
end

should "have the number in the right half of the array" do
assert_equal(binary_search(@input_array,5),true)
assert_equal(binary_search(@input_array,4),true)
end

should "have the number in the middle of the array" do
assert_equal(binary_search(@input_array,3),true)
end

should "not have the number in the array" do
assert_equal(binary_search(@input_array,6),false)
end

def teardown
#nothing to do here
end
end

context "Input array of size 1" do

def setup
@input_array = [1]
end

should "have the number in the array" do
assert_equal(binary_search(@input_array,1),true)
end

should "not have the number in the array" do
assert_equal(binary_search(@input_array,2),true)
end

def teardown
#nothing to do here
end
end
end

Notice that we are still sub-classing the Test::Unit::TestCase class. In this example we have two contexts one for input array of size 5 and the other for input array of size 1. Each context has its own environment of setup/teardown methods. We can also create nested contexts - the outer setup gets run before the execution of each of the inner contexts. And the setup in the inner contexts gets run when running that context. Each should construct is converted into individual test methods and are run. If a test case fails we will get a better description of what that test case is doing from the should description.

=RSpec=

Now let us consider about RSpec Testing Framework in detail.

==Background==

Behaviour Driven Development (BDD) [http://en.wikipedia.org/wiki/Behavior_Driven_Development] is an Agile development process [http://en.wikipedia.org/wiki/Agile_software_development] that comprises aspects of Acceptance Test Driven Planning [http://www.springerlink.com/content/978-3-540-22839-4/] [http://en.wikipedia.org/wiki/Acceptance_testing], Domain Driven Design [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Domain-driven_design] and Test Driven Development (TDD). [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Test-driven_development] RSpec is a Behavioural Driven Development (BDD) tool aimed at Test Driven Development, originally created by Dave Astels and Steven Baker. However David Chelimsky [http://blog.davidchelimsky.net/] is really the gatekeeper of the RSpec project. [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]

Traditionally we use Unit Test frameworks like JUnit, NUnit or RUnit for writing Test cases. We spend a lot of time writing tests that test every unit of code in our software system. Instead we can shift our focus from Unit testing to Behaviour testing or Behaviour Driven Development (BDD) using RSpec. By focusing on the behaviour of the system it helps clarify in our minds what the system should actually be doing. It also helps us to perform more ‘useful’ tests. Useful tests, cover what the system should be doing and build in enough redundancy so that it should be easy to refactor our code without having to re-write every test. 

RSpec is really two projects merged into one. The RSpec project pages describes these merged projects as:

# application level behaviour described by a Story Framework 
# object level behaviour described by a Spec Framework 

Dan North created rbehave [http://blog.dannorth.net/2007/06/17/introducing-rbehave/] which is the Story Framework and David Chelimsky created the Spec Framework. By encompassing two frameworks RSpec equips a programmer with a thorough set of testing tools, allowing you to think about your software problem from a number of perspectives.

==Prerequisites==

The prerequisites are

# Ruby 1.8.4 or later
# RSpec Gem (latest)

To install Ruby, please visit official Ruby Website [http://www.ruby-lang.org/] 
To install RSpec, open a command shell, go to /bin folder in Ruby directory and type 
> gem install rspec

==Terms & Definitions==

Here are some terms which are used frequently while working with RSpec. [http://www.pragprog.com/titles/achbd/the-rspec-book/ ]

# subject code - The code whose behavior is specified using RSpec
# expectation - The expected behavior of subject code is expressed using expectation (Similar to 'Assertions' statements used in Test::Unit or other tools in other languages)
# code example - An executable example containing the subject code and the expectations (Similar to 'Test Method' terminology used elsewhere)
# example group - A group of code examples (Similar to 'Test Case' terminology used elsewhere)
# spec file - A file which contains one or more example groups

==Example==

Let us go through an example to be clear on the usage of RSpec.

require 'binarysearch'

describe BinarySearchTest do
before(:all) do
@input_array = [1, 2, 3, 4, 5] # The Input Array
end

after(:all) do
# do nothing here
end

it "should be in the left-half of the array" do # Test case for element to be present in left-half of given array
bst = BinarySearch.new
bst.should be_binary_search(1)
end

it "should be in the right-half of the array" do # Test case for element to be present in right-half of given array
bst = BinarySearch.new
bst.should be_binary_search(5)
end

it "should be in the middle of the array" do # Test case for element to be present in the middle of given array
bst = BinarySearch.new
bst.should be_binary_search(3)
end

it "should not be in the array" do # Test case for element NOT to be present in given array
bst = BinarySearch.new
bst.should_not be_binary_search(7)
end
end

Here it is assumed that the method binary_search will return true/false based on whether the provided value exists in the array or not.

====describe() method====

The describe() method can take an arbitrary number of arguments and a block and returns a sub-class of Spec::Example::ExampleGroup. We generally use only one or two arguments which is used to describe the behavior. The first argument can be a reference to a Class or module or a string. The second argument is optional and should be a string when used.

====it() method====

Similar to the describe() method, the it() method takes a single String, an optional Hash and an optional block. The String expression within the it() should be such that it informs the behavior of the code within the block.

==Expectations in RSpec==

There are two methods available for checking expectations: should() and should_not(). Both the methods accept either an expression matcher or a Ruby expression using a specific subset of Ruby operators. An expression matcher is an objects that matches an expression.

===Built-in Matchers===

There are several matchers that can be used with should and should_not, which are divided into well-separated categories.
====Equality====
subject.should == ece517
subject.should === ece517
subject.should eql(subject)
subject.should equal(subject)

The == method is used to express equivalence and equal is used when you want the receiver and the argument to be the same object. Instead of using !=, you should use the should_not method!

====Floating Point Calculations====
piValue.should be_close(3.14, 0.001593)

Sometimes the values generated might be correct upto some fixed decimal positions, after that they may have slight variations. To avoid the test beings failed, we provide the (value, delta) to be_close method which passes the test if the obtained value lies within the range (value+delta).

====Regular Expressions====
resultExpression.should match(/this regular expression/)
resultExpression.should =~ /this regular expression/

This can be very useful when dealing with multiple-line expectations, instead of using the open file technique to compare contents.

====Changes====
lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.to(1)

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.from(0).to(1)

This is really useful when working with database changes or changes to objects. The matcher is change(), which takes a block and accepts the from(), to() or by() modifiers. [18]

====Errors====
field = CricketGround.new(:players => 11)
lambda {
field.remove(:players, 15)
}.should raise_error(NotEnoughPlayers,“attempted to remove more players than there is on cricket stadium”)

Useful when needed to check for Exceptions. The matcher is raise_error and takes an ExceptionObject and/or a String/Regexp.

====Throw====
speech = Speech.new(:seats => 100)
100.times { speech.register Person.new }
lambda {
speech.register Person.new
}.should throw_symbol(:speech_full, 100)

When dealing with “errors that are not really exceptions”, you use catch and throw. Rspec can check if a throw has been called by using the throw_symbol matcher. It accepts 0,1 or 2 arguments. The first argument needs to be a Symbol and the second can be any Object that is thrown along.

===Predicate Matchers===
A Ruby predicate method is a method that ends with a “?” and returns a boolean value, like string.empty? or regexp.match? methods. Instead of writing:
a_string.empty?.should == true
We can write using RSpec:
a_string.should be_empty

When using a be_something matcher, RSpec removes the “be_”, appends a “?” and calls the resulting method in the receiver. A very common construct of this method is be_true, which checks if the receiver is true (any object except false or nil) or false (false or nil).

===Check Ownership===
Sometimes you will want to check something the object owns and not the object itself.

====The have_something() method====
security_access.has_key?(:id).should == true
is the same as
security_access.should have_key(:id)

RSpec uses method_missing to convert anything that begins with have_something to has_something? and performs the checking.

====The have() method====
field.players.select {|p| p.team == home_team }.length.should == 9
is the same as
home_team.should have(9).players_on(field)

As have() does not respond to players_on(), it delegates to the receiver (home_team). It encourages the home_team object to have useful methods like players_on. 
You can get a NoMethodError if the players_on method doesn´t exist, you can get another NoMethodError if the result of the players_on method doesn´t respond to size() or length() and if the size of the collection doesn´t match the expected size, you will get a failed expectation. [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/]

===Checking Collections Themselves===
Sometimes we create expectations about a collection itself and not about an owned collection. RSpec lets us use the have() method to express this as well, as in:
basket_collection.should have(10).items
items is just providing some meaning to the expectation.

====Strings====
Strings are not collections by definition but they respond to a lot of methods that collections do, like length() and size(). This allow us to use have() to expect a string of a specific length.
“apple”.should have(5).characters
characters is just providing meaning to the expectation as well.

====Have() modifiers for precision====
The have() method has some relatives that allow us to check for upper and lower conditions.

work.should have_exactly(8).hours
classroom.should have_at_most(100).people
bag.should have_at_least(5).items

===Operator Expressions===
There may be sometimes when you want to expect a value to be not an exact amount but something like greater than or less than. RSpec allows you to do this by using the regular operators from Ruby!

number.should == 3
number.should be >= 2
number.should be <= 4
number should be > 0

=References=

# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Programming & Unit Testing]. en.wikibooks.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Ruby Test::Unit]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Ruby Assertions]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html Shoulda Explained]. pragprog.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavior Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://www.springerlink.com/content/978-3-540-22839-4/ Proceedings] Carmen Zannier, Hakan Erdogmus and Lowell Lindstrom. Extreme Programming and Agile Methods - XP/Agile Universe 2004. 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, August 15-18, 2004.
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false Domain-driven design: tackling complexity in the heart of software]. By Eric Evans. books.google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Domain-driven_design Domain Driven Design]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false Test-driven development: by example]. By Kent Beck. books. google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://blog.davidchelimsky.net/ David Chelimsky Blog]. davidchelimsky.net. Retrieved Sep 17, 2010.
# [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/ Understanding RSpec Stories - A Tutorial]. emson.co.uk. Retrieved Sep 17, 2010.
# [http://blog.dannorth.net/2007/06/17/introducing-rbehave/ rbehave]. dannorth.net. Retrieved Sep 17, 2010.
# [http://www.ruby-lang.org Ruby Website]. ruby-lang.org. Retrieved Sep 17, 2010.
# [http://www.pragprog.com/titles/achbd/the-rspec-book RSpec Book]. pragprog.com. Retrieved Sep 17, 2010.
# [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/ RSpec - Expectations]. wordpress.com. Retrieved Sep 17, 2010.

CSC/ECE 517 Fall 2010/ch1 1f vn

2010-09-18T01:05:41Z

Thatvamasi: /* Prerequisites */

='''Unit-Testing Frameworks for Ruby'''=

This wiki-page serves as a knowledge source for understanding the different Unit-Testing Frameworks available for Ruby. 

__TOC__

=Introduction=
Unit testing is a method by which we can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written. [http://en.wikipedia.org/wiki/Unit_testing] It helps to identify errors in the program even without running the entire program. It also helps to do regressing testing to identify buggy code additions in the future. Unit testing frameworks provides us with constructs which simplifies the process of unit testing. Using a standard unit test framework helps other developers to add test cases easily. [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing] This chapter walks through three different unit testing frameworks available for Ruby and explains how to use them with examples. The three commonly used unit testing frameworks for ruby are

# Test::Unit
# Shoulda
# RSpec

=Test::Unit=

==Background==
Ruby comes with an in-built, ready to use unit testing framework called Test::Unit. It is a XUnit type framework and typically have a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests themselves are bundled separately in a test class from the code it is testing.

==Test Fixture==
Test fixture represents the initial environment setup(eg. initialization data) and/or the expected outcome of the tests for that environment. This is typically done in the setup() and teardown() methods and it helps to separate test initialization and cleanup from the actual tests. It also helps to reuse the same fixture for more than one tests.[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html]

For example, consider a method prime_check(num) which takes an integer number as input and outputs whether it is prime number or not. In order to unit test this method we can create the following fixture containing a 2-dimensional array with a number and the expected output of whether it is prime or not.

def setup
@NUMBERS = [[3,true], [4,false], [7,true], [10,false]]
end

==Assertions==
The core part of test::unit framework is the ability to assert a statement of expected outcome. If an assert statement is correct then the test will proceed, otherwise the test will fail. This feature helps us to verify the method under test with different types of inputs and track the results. Test::unit provides a bunch of assert methods for this purpose:

{| border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

For the full list of assertion methods provided by test::unit refer to test::unit assertions. [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html]

==Example==
The test case class BinarySearchTest subclasses the Test::Unit::TestCase class and overrides setup and teardown methods. The test methods should start with 'test_' prefix. This helps in isolating the test methods from the helper methods if any. The Test::Unit::TestCase class takes care of making the test methods into tests, wrapping them into a suite and running the individual tests. The test results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

def setup
@input_array = [1,2,3,4,5]
end

def test_success_left_half
assert_equal(binary_search(@input_array,1),true)
assert_equal(binary_search(@input_array,2),true)
end

def test_success_right_half
assert_equal(binary_search(@input_array,5),true)
assert_equal(binary_search(@input_array,4),true)
end

def test_success_middle
assert_equal(binary_search(@input_array,3),true)
end

def test_failure
assert_equal(binary_search(@input_array,6),false)
end

def teardown
#nothing to do here
end

end

Here we have four test methods testing different logical paths of the binary search algorithm. Each test method can have one or more assert statements to test whether conditions are correct in each situation. To run the tests we simply have to run the file binary_search_test.rb and the output is as follows:

Loaded suite binarysearch
Started
F...
Finished in 0.372 seconds.

1) Failure:
test_failure(BinarySearchTest) [binarysearch.rb:25]:
<true> expected but was
<false>.

4 tests, 6 assertions, 1 failures, 0 errors

The results show that the last test case test_failure, testing the negative scenario is failing. The reason is because the assert statement is expecting false when number 6, which not present in the array is passed. But the binary_search method is returning true.

==Test Suite==
Sometimes it is useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose. The below example demonstrates how to bundle binary and sequential test case classes into a single search test suite.

require 'test/unit/testsuite'
require 'binary_search_test'
require 'sequential_search_test'

class Search_Tests
def self.suite
suite = Test::Unit::TestSuite.new
suite << BinarySearchTest.suite
suite << SequentialSearchTest.suite
return suite
end
end
Test::Unit::UI::Console::TestRunner.run(Search_Tests)

=Shoulda=

==Background==
One of the downsides of Test::Unit is we end up writing lots of code in order to test the actual code which is sometimes not easy to understand. Shoulda is a library that allows us to write better and more understandable tests for ruby application. Shoulda is not a testing framework by itself. It extends the Test::Unit framework with the idea of context. We can mix Test::Unit test cases with Shoulda test cases. Shoulda allows us to provide context to the tests so that we can group the tests according to a specific feature or scenario. [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html]

==Example==
require 'shoulda'
require 'test/unit'
require 'binarysearch'

class BinarySearchTest < Test::Unit::TestCase

context "Input array of size 5" do

def setup
@input_array = [1,2,3,4,5]
end

should "have the number in the left half of the array" do
assert_equal(binary_search(@input_array,1),true)
assert_equal(binary_search(@input_array,2),true)
end

should "have the number in the right half of the array" do
assert_equal(binary_search(@input_array,5),true)
assert_equal(binary_search(@input_array,4),true)
end

should "have the number in the middle of the array" do
assert_equal(binary_search(@input_array,3),true)
end

should "not have the number in the array" do
assert_equal(binary_search(@input_array,6),false)
end

def teardown
#nothing to do here
end
end

context "Input array of size 1" do

def setup
@input_array = [1]
end

should "have the number in the array" do
assert_equal(binary_search(@input_array,1),true)
end

should "not have the number in the array" do
assert_equal(binary_search(@input_array,2),true)
end

def teardown
#nothing to do here
end
end
end

Notice that we are still sub-classing the Test::Unit::TestCase class. In this example we have two contexts one for input array of size 5 and the other for input array of size 1. Each context has its own environment of setup/teardown methods. We can also create nested contexts - the outer setup gets run before the execution of each of the inner contexts. And the setup in the inner contexts gets run when running that context. Each should construct is converted into individual test methods and are run. If a test case fails we will get a better description of what that test case is doing from the should description.

=RSpec=

Now let us consider about RSpec Testing Framework in detail.

==Background==

Behaviour Driven Development (BDD) [http://en.wikipedia.org/wiki/Behavior_Driven_Development] is an Agile development process [http://en.wikipedia.org/wiki/Agile_software_development] that comprises aspects of Acceptance Test Driven Planning [http://www.springerlink.com/content/978-3-540-22839-4/] [http://en.wikipedia.org/wiki/Acceptance_testing], Domain Driven Design [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Domain-driven_design] and Test Driven Development (TDD). [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false] [http://en.wikipedia.org/wiki/Test-driven_development] RSpec is a Behavioural Driven Development (BDD) tool aimed at Test Driven Development, originally created by Dave Astels and Steven Baker. However David Chelimsky [http://blog.davidchelimsky.net/] is really the gatekeeper of the RSpec project. [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]

Traditionally we use Unit Test frameworks like JUnit, NUnit or RUnit for writing Test cases. We spend a lot of time writing tests that test every unit of code in our software system. Instead we can shift our focus from Unit testing to Behaviour testing or Behaviour Driven Development (BDD) using RSpec. By focusing on the behaviour of the system it helps clarify in our minds what the system should actually be doing. It also helps us to perform more ‘useful’ tests. Useful tests, cover what the system should be doing and build in enough redundancy so that it should be easy to refactor our code without having to re-write every test. 

RSpec is really two projects merged into one. The RSpec project pages describes these merged projects as:

# application level behaviour described by a Story Framework 
# object level behaviour described by a Spec Framework 

Dan North created rbehave [http://blog.dannorth.net/2007/06/17/introducing-rbehave/] which is the Story Framework and David Chelimsky created the Spec Framework. By encompassing two frameworks RSpec equips a programmer with a thorough set of testing tools, allowing you to think about your software problem from a number of perspectives.

==Prerequisites==

The prerequisites are

# Ruby 1.8.4 or later
# RSpec Gem (latest)

To install Ruby, please visit official Ruby Website [http://www.ruby-lang.org/] 
To install RSpec, open a command shell, go to /bin folder in Ruby directory and type 
> gem install rspec

==Terms & Definitions==

Here are some terms which are used frequently while working with RSpec. [http://www.pragprog.com/titles/achbd/the-rspec-book/ ]

# subject code - The code whose behavior is specified using RSpec
# expectation - The expected behavior of subject code is expressed using expectation (Similar to 'Assertions' statements used in Test::Unit or other tools in other languages)
# code example - An executable example containing the subject code and the expectations (Similar to 'Test Method' terminology used elsewhere)
# example group - A group of code examples (Similar to 'Test Case' terminology used elsewhere)
# spec file - A file which contains one or more example groups

==Example==

Let us go through an example to be clear on the usage of RSpec.

require 'binarysearch'

describe BinarySearchTest do
before(:all) do
@input_array = [1, 2, 3, 4, 5] # The Input Array
end

after(:all) do
# do nothing here
end

it "should be in the left-half of the array" do # Test case for element to be present in left-half of given array
bst = BinarySearch.new
bst.should be_binary_search(1)
end

it "should be in the right-half of the array" do # Test case for element to be present in right-half of given array
bst = BinarySearch.new
bst.should be_binary_search(5)
end

it "should be in the middle of the array" do # Test case for element to be present in the middle of given array
bst = BinarySearch.new
bst.should be_binary_search(3)
end

it "should not be in the array" do # Test case for element NOT to be present in given array
bst = BinarySearch.new
bst.should_not be_binary_search(7)
end
end

Here it is assumed that the method binary_search will return true/false based on whether the provided value exists in the array or not.

====describe() method====

The describe() method can take an arbitrary number of arguments and a block and returns a sub-class of Spec::Example::ExampleGroup. We generally use only one or two arguments which is used to describe the behavior. The first argument can be a reference to a Class or module or a string. The second argument is optional and should be a string when used.

====it() method====

Similar to the describe() method, the it() method takes a single String, an optional Hash and an optional block. The String expression within the it() should be such that it informs the behavior of the code within the block.

==Expectations in RSpec==

There are two methods available for checking expectations: should() and should_not(). Both the methods accept either an expression matcher or a Ruby expression using a specific subset of Ruby operators. An expression matcher is an objects that matches an expression.

===Built-in Matchers===

There are several matchers that can be used with should and should_not, which are divided into well-separated categories.
====Equality====
subject.should == ece517
subject.should === ece517
subject.should eql(subject)
subject.should equal(subject)

The == method is used to express equivalence and equal is used when you want the receiver and the argument to be the same object. Instead of using !=, you should use the should_not method!

====Floating Point Calculations====
piValue.should be_close(3.14, 0.001593)

Sometimes the values generated might be correct upto some fixed decimal positions, after that they may have slight variations. To avoid the test beings failed, we provide the (value, delta) to be_close method which passes the test if the obtained value lies within the range (value+delta).

====Regular Expressions====
resultExpression.should match(/this regular expression/)
resultExpression.should =~ /this regular expression/

This can be very useful when dealing with multiple-line expectations, instead of using the open file technique to compare contents.

====Changes====
lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.to(1)

OR

lambda {
User.create!(:role => "admin" )
}.should change{ User.admins.count }.from(0).to(1)

This is really useful when working with database changes or changes to objects. The matcher is change(), which takes a block and accepts the from(), to() or by() modifiers. [18]

====Errors====
field = CricketGround.new(:players => 11)
lambda {
field.remove(:players, 15)
}.should raise_error(NotEnoughPlayers,“attempted to remove more players than there is on cricket stadium”)

Useful when needed to check for Exceptions. The matcher is raise_error and takes an ExceptionObject and/or a String/Regexp.

====Throw====
speech = Speech.new(:seats => 100)
100.times { speech.register Person.new }
lambda {
speech.register Person.new
}.should throw_symbol(:speech_full, 100)

When dealing with “errors that are not really exceptions”, you use catch and throw. Rspec can check if a throw has been called by using the throw_symbol matcher. It accepts 0,1 or 2 arguments. The first argument needs to be a Symbol and the second can be any Object that is thrown along.

===Predicate Matchers===
A Ruby predicate method is a method that ends with a “?” and returns a boolean value, like string.empty? or regexp.match? methods. Instead of writing:
a_string.empty?.should == true
We can write using RSpec:
a_string.should be_empty

When using a be_something matcher, RSpec removes the “be_”, appends a “?” and calls the resulting method in the receiver. A very common construct of this method is be_true, which checks if the receiver is true (any object except false or nil) or false (false or nil).

===Check Ownership===
Sometimes you will want to check something the object owns and not the object itself.

====The have_something() method====
security_access.has_key?(:id).should == true
is the same as
security_access.should have_key(:id)

RSpec uses method_missing to convert anything that begins with have_something to has_something? and performs the checking.

====The have() method====
field.players.select {|p| p.team == home_team }.length.should == 9
is the same as
home_team.should have(9).players_on(field)

As have() does not respond to players_on(), it delegates to the receiver (home_team). It encourages the home_team object to have useful methods like players_on. 
You can get a NoMethodError if the players_on method doesn´t exist, you can get another NoMethodError if the result of the players_on method doesn´t respond to size() or length() and if the size of the collection doesn´t match the expected size, you will get a failed expectation. [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/]

===Checking Collections Themselves===
Sometimes we create expectations about a collection itself and not about an owned collection. RSpec lets us use the have() method to express this as well, as in:
basket_collection.should have(10).items
items is just providing some meaning to the expectation.

====Strings====
Strings are not collections by definition but they respond to a lot of methods that collections do, like length() and size(). This allow us to use have() to expect a string of a specific length.
“apple”.should have(5).characters
characters is just providing meaning to the expectation as well.

====Have() modifiers for precision====
The have() method has some relatives that allow us to check for upper and lower conditions.

work.should have_exactly(8).hours
classroom.should have_at_most(100).people
bag.should have_at_least(5).items

===Operator Expressions===
There may be sometimes when you want to expect a value to be not an exact amount but something like greater than or less than. RSpec allows you to do this by using the regular operators from Ruby!

number.should == 3
number.should be >= 2
number.should be <= 4
number should be > 0

=References=

# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Programming & Unit Testing]. en.wikibooks.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Ruby Test::Unit]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Ruby Assertions]. ruby-doc.org. Retrieved Sep 17, 2010.
# [http://pragdave.blogs.pragprog.com/pragdave/2008/04/shoulda-used-th.html Shoulda Explained]. pragprog.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavior Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://www.springerlink.com/content/978-3-540-22839-4/ Proceedings] Carmen Zannier, Hakan Erdogmus and Lowell Lindstrom. Extreme Programming and Agile Methods - XP/Agile Universe 2004. 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, August 15-18, 2004.
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=7dlaMs0SECsC&dq=domain+driven+design&printsec=frontcover&source=bn&hl=en&ei=ZPaTTJvIDIKB8gaykp2NDA&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CCwQ6AEwAw#v=onepage&q&f=false Domain-driven design: tackling complexity in the heart of software]. By Eric Evans. books.google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Domain-driven_design Domain Driven Design]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://books.google.com/books?id=gFgnde_vwMAC&printsec=frontcover&dq=test+driven+development&source=bl&ots=enLsruWrsF&sig=9pEP988f2rJQUmDd73Ka_3jrcCQ&hl=en&ei=IfeTTIcMwoHyBtXe8ZEM&sa=X&oi=book_result&ct=result&resnum=3&sqi=2&ved=0CD8Q6AEwAg#v=onepage&q&f=false Test-driven development: by example]. By Kent Beck. books. google.com. Retrieved Sep 17, 2010.
# [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. en.wikipedia.org. Retrieved Sep 17, 2010.
# [http://blog.davidchelimsky.net/ David Chelimsky Blog]. davidchelimsky.net. Retrieved Sep 17, 2010.
# [http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/ Understanding RSpec Stories - A Tutorial]. emson.co.uk. Retrieved Sep 17, 2010.
# [http://blog.dannorth.net/2007/06/17/introducing-rbehave/ rbehave]. dannorth.net. Retrieved Sep 17, 2010.
# [http://www.ruby-lang.org Ruby Website]. ruby-lang.org. Retrieved Sep 17, 2010.
# [http://www.pragprog.com/titles/achbd/the-rspec-book RSpec Book]. pragprog.com. Retrieved Sep 17, 2010.
# [http://rubynoobie.wordpress.com/2010/01/27/rspec-expectations/ RSpec - Expectations]. wordpress.com. Retrieved Sep 17, 2010.