CISC 3142
Programming Paradigms in C++
Preliminaries

Java Compilation / Interpretation vs C++ Compilation / Linking / Execution

• compilation vs interpretation
• compiling multiple source files

Java

• virtual machines
• single compilation compiles all files on command line — javac *.java
• compiler goes out looking for types and declarations in .class (using CLASSPATH
  • in the absence of a viable .class file, the compiler can also go out looking for corresponding source (.java) files and compiles them
• class files and class loading (dynamic)

C++

• object files, linking, and executable files (static)
• compiler looks at, and compiles, only the specified, single source file only … does not look elsewhere
  • Thus, g++ *.cpp is exactly the same as if you had written g++ ....cpp for each .cpp file in the directory
  • however, the preprocessor brings #include'd files into the source file

Scope and Lifetime

• scope: portion of program where variable is visible/accessible (qualified? / unqualified?)
• lifetime: portion of program where variable/value is in existence/is valid
• difference between lifetime and scope
  • scope is a compile time concept
  • lifetime is a runtime concept

Scope

• shadowing
  • the situation where a variable 'hides' another variable of the same name, typically due to scoping

  class C {
  	…
  	void f() {
  		int x;
  	}
  	…
  	private int x;
  }
  

Java

• instance variable (class scope), method parameter, local variable (local scope; declared within a block, i.e., within {}'s)(, exception-handler parameter)
• use of same name and this in constructor or set methods - class vs local scope
• optional use of this in methods

C++

• same basic scopes as Java, with the additions of namespace scope and global scope

Lifetime (allocation / storage duration)

• static (global) / automatic (stack) / dynamic (programmer-controlled / heap)
• local variables, instance variables, class variables
• dynamic objects
• lifetime of variables vs lifetime of objects

  void f() {
  	…
  	Employee e = new Employee(…);
  	…
  }
  		

  • e is created upon entry to the method; and destroyed upon exit
  • the Employee object is created when new is invoked; when its lifetime ends is not our concern in Java; in C++ it;s is destroyed when delete is invoked.

Java

• primitive values vs objects
• mainly dynamic memory — objects live on the heap
  • programmer controlled creation, but not destruction (automatic garbage collection)

C++

• all durations are equally present and supported
• programmer-controlled creation and destruction of heap-based objects
  • memory-management is thus a much larger concern than in Java

Categories of values, objects, variables

Java

• primitive values/variables, objects (class and array), and reference variables (class and array)

C++

• Basic types
  • fundamental types,
  • compound types: arrays, pointers, references
    • These are types that are built up from an element type
  • user-defined types: classes, structs, enumerations
    • the user defines the structure of such types, i.e., the collection of fields
• object (Stroustrup … something in memory)
  • refers not just to class / array types, but anything
• lvalue and rvalue
  • loosely speaking, an lvlaue is something that has a memory location that can be assigned to; an rvalue only has a value, no location
    • lvalue stands for something that can appear on the left hand side of an assignment; rvalue for something that can only appear on the right.
      • thus, for an rvalue, we are mainly concerned with the value; for an lvalue, the location
      • literals, expression results are not lvalues
    • there's more to it than that, but it's a decent first approximation

  int x, y;
  
  y = 7;
  x = y;
  // 12 = x;		// 12 is not an lvalue
  		

  

Reference and Value-semantics

Aliases vs Copies

• Creating an alias requires a level of indirection

Java

• Assigning a primitive results in a copy, also known as a clone (value-semantics)
  • Since there are no references to primitives in Java, no infraction can be used and thus no aliasing of primitives is possible
• Assigning a reference results in an alias to the object being referred to (reference semantics)
  • To get a copy of an object, one must either use a copy constructor, or a copy method (sometimes named clone):

Copy Constructors and Copy Methods in Java

• We can impose value-semantics on top of of reference semantics by introducing methods that make independent copies of the object.
• For the following examples, assume the class SomeClass that has (as needed) the methods shown and the following instance variable:

  class SomeClass {
  	…
  	iprivate int intVar;
  	private String stringVar;
  }
  		

• In copy constructors and methods, the copy is typically achieved by memberwise copying of the fields of the source object to the destination object.

  dest.intVar = src.intvar;
  dest.stringVar = src.stringVar;
  		

  where src (the ref var to the source object) and dest (ref var to the destination object) can be the receiver (this, a parameter to the method (we will add the suffix Parm for clarity), or a local variable; we'll have examples of each below.
  • if more than one such copy mechanism is implemented, a workhorse method is often introduced to do the memberwise copying

Copy Constructor

• The copy constructor is invoked after the object has been created via an invocation of new
• It accepts a parameter if the same class as the newly created object
• This is the standard approach to creating a copy of an object

class SomeClass {
	SomeClass(SomeClass srcParm) {	// constructor taking object of same class
		intVar = srcParm.intVar;				// or this.intVar = srcParm.intVar
		stringVar = srcParm.stringVar;	
	}
	…
	private int intVar;
	private String stringVar;
}

Usage:

SomeClass dest = new SomeCLass(src);

In-Place Copy Method

• The in-place copy method makes the receiving object a copy of an existing object a copy of the parameter
  • The existing object's value is changed in-place
• Notice it is the destination object that is the receiver here
  • Of the three copy methods, this is probably the most commonly used — and most sensible — for several reasons:
    • The object that is getting the copy is the receiver, and should thus responsible be for its own copy
  • It is the parallel to the copy constructor iexcept the copy is to an existing object
    • In both instances the destination is the receiver and the source is the parameter.
  • The copy method can act as a workhorse for the constructor so both share the same object=specific code to perform the memberwise copy
    • This enforces consistent semantics between the creation of these object via a copy and the mutation of an existing object to a copy of another object
    • We'll further discuss workhorses in the context of leveraging below.

class SomeClass {
	…
	void copy(SomeCLass r1) {	// copy method taking object of same class
		intVar = r1.intVar;				// overwrites existing value of instance variable; again this.intVar = r1.intVar
		stringVar = r1.stringVar;	
	}
}

Two Less-Common Copy Methods

The following two methods also achieve a copy, however their logic doesn't parallel that of a constructor (the first one), or is not object-oriented (second).

'Cloning' Copy (Instance) Method

• In the cloning copy, the copy method, the source is the receiver
• The method that creates a new object in this case, and, and again a memberwise copy is performed
• A reference to the newly created object is returned from the method
  • Typically, this reference is then assigned to the destination reference var
• Notice it is the source object here that is the receiver
  • This is a touch counter-intuitive -- to have the source be in charge of the copy of the destination; objects should in general be in charge of their state … not others.
• Also note that the parameter (the destination reference) may already be pointing at an object in which case we are redirecting it to the new object. This could case the original destination object to become garbage if there are no other references to it.
• Finally, note how the logic differs from the copy constructor (i.e., which ref var is on the rhs and lhs of the memberwise copies).

class SomeClass {
	…
	SomeClassvoid copy() {	// copy method taking object of same class
		SomeCLass result = new SomeClass();
		result.intVar = intVar1;				// or result.intVar = this.intVar
		result.stringVar = stringVar;	
	}
}

SomeClass dest = src.copy();		

or

dest = src.copy();		// redirects existing reference to new object

Static Copy Method

• Source and destination references are sent as arguments to a static method
  • no receiver
  • this method would probably reside within the object's class, but need not, which would present the issue of data access to the private instance variables
• Not very OOPy; BUT …
  • This method can be reside outside the class (for example in utility library separate from the class) since there's no receiver
  • Being as there is no receiver, the objects are treated symmetrically and the logic reflects that.
    • This will prove useful when we do this in C++

class SomeClass {
	…
	static void copy(SomeCLass destParm, SomeCLass srcParm) {	
		destParm.intVar = srcParmr1.intVar1;				
		destParm.stringVar = srcParmr1.stringVar;	
	}
}

copy(dest, src));		

A More Involved Example

class Integer {
	Integer(int val) {this.val = val;}
	Integer(Integer integer) {val = integer.val;}	// copy constructor
	…
	void copy(Integer integer) {val = integer.val;}	// in-place copy method
	…
	int val;
}
…
Integer i1 = new Integer(3);		// uses 'int' constructor
Integer i2 = new Integer(12);		// uses 'int' constructor
Integer i3 = new Integer(i1);		// uses copy constructor — clone
Integer i4 = i1;			// reference assignment — alias
i2.copy(i3);				// in-place copy method — clone
i2 = new Integer(i4);			// copy constructor — clone

C++

• C++ supports reference- and value-semantics for any data type
  • It also has a const reference to provide the best of both worlds for large objects:
    • minimize data copying
    • prevent inadvertent modification
• We'll see all this later as we get into C++

Mutability vs Immutability

Some classes are deliberately designed so that their objects — once initialized — cannot be modified

• Such a class is called an immutable class
• This is in contrast with a mutable class whose objects can be modified

• The operations in an immutable class always produce a new object of the class (rather than modifying one of the operands
  • This is similar to the simple arithmetic operations, e.g., a + b, the result of the operation is a new value
  • Such operations are called pure (or as we said immutable);
  • In some sense immutability allows Java to impose value semantics on top of reference semantics
• The operations of a mutable class typically modify the receiver
  • This corresponds to the compound assignment operations, e.g., a += b, the result of the operation is stored in the left operand
  • Such operations are calleded in-place

Immutable Classes

class ImmutableColor {
	public ImmutableColor(int r, int g, int b) {
		this.r = r;
		this.g = g;
		this.b = b;
	}
	…
	public ImmutableColor lighter() {
		if (r < 255 && g < 255 && b < 255) 
			return new ImmutableColor(r+1, g+1, b+1)
		else
			return null;	
	}

	private final int r, g, b;
}

Mutable Classes

class MutableColor {
	public MutableColor(int r, int g, int b) {
		this.r = r;
		this.g = g;
		this.b = b;
	}
	…
	public MutableColor makeLighter() {
		if (r < 255 && g < 255 && b < 255)  {
			r++;
			g++;
			b++
			return this;
		}
		else
			return null;	
	}

	private int r, g, b;
}

Criteria for Mutability/Immutability

• Immutable: when an object is aliased by many variable, each expecting it's value to remain unchanged unless it alone makes the modification
  • example: String
• Mutable: when changes to an object should be reflected among all aliases
  • example: containers
  • note that there is a need for immutable containers as well, i.e., when the container takes part in a modification operations (e.g., adding an element) a new copy of the container is made, and the element added to it, the original remains untouched, and the copy becomes the result of the operation.

A Closer Look: String vs ArrayList

• String vs ArrayList
• String
  • strings are essentially single value — i.e., we normally don't think of the individual characters of the string
  • if a variable is referencing a String, it is therefore referencing a single value, which is not expected to change
  • if there are two aliases to the same String object, one should not be able to change the contents of the String object as it will affect the value for both references
    • rather a new copy of the object should be made, and its refernce assigned to the variable being operated on, and the change made to the new object
  • for example, there is no setCharAt method for String. as that would involve an in-place modification to the String object
  • all modification methods produce a new String object
    • We can achieve a similar effect to the change in place if we assign the reference to the new string object to the reference variable currently pointing to the original object.

      String s = "Hello world!";
      s = s.substring(0, 5);
      						

      
      • We will see this pattern below in the context of wanting to modify the receiver of a method
• ArrayList
  • ArrayList is a container, essentially containing a dynamically sized array
    • It's irrelevant to this particular discussion, but the array resize method presented above is at the heart of the dynamic sizing
  • We expect (and want) the contents (elements) of an ArrayList to change
    • for example, given an ArrayList of Employee objects, if we were to iterate the list and give all employees a 10% raise, we would want that reflected whenever any other part of the system access an employee object.
  • The ArrayList itself is merely the container, it's the elements that are of real interest
  • If there are two aliases to the same ArrayList object, modifications made by one to the contents of the ArrayList object is (typically) of interest to all
  • Most ArrayList methods are therefore in-place; i.e., they do not create a new container; rather they modify elements in the receiving container

    ArrayList aList = new ArrayList();
    aList.add(12);
    				

    

Parameter transmission

Basic Terminology

• Thus in:

  swap(a, b);		// a & b are arguments
  …
  void swap(int x, int y) {…}	// x & y are parameters
  		

Call-by-Value

• call-by-value refers to a method of passing arguments to parameters, where the value of the argument is passed
  • This is most easily thought of — and typically implemented — as a copy of the argument is assigned to the parameter
    

• When reference variables are the arguments, it is the value of the reference, not the object that is passed

  

  • Not understanding this distinction is the cause of much misunderstanding, and in particular the origin of the notion that Java has some form of call-by-reference — it doesn't

Java

• has call-by-value only; there is no call-by-reference
  • arguments are copied to the parameters upon invocation
  • parameters are not copied back upon return
    • changes to parameters therefore have no effect on calling argument

The Problem with Swapping Two Values in Java

• a (surprising, but logical) consequence is the inability to write simple swap method in Java
  • swapping primitive variables — doesn't work

    static void swap(int x, int y) {	
    	int t = x;
    	x = y;
    	y = t;
    }
    				

    
    • since the arguments are passed by value (again, copied to the parameters), changes in method do not persist upon return
  • swapping reference variables results in the same problem — doesn't work

    static void swap(String x, String y) {	
    	String t = x;
    	x = y;
    	y = t;
    }
    				

    
    • again, it is the value of the reference variables (think of it as the memory locations) that are passed (and swapped), not the objects
      • the parameters — with their changes — are destroyed upon exit, result in no change to the arguments

Swapping in Java

• to properly perform a swap in Java, you need indirection either through an array and indexes, or by embedding the values to be swapped in an object
  • As you will see, these both are actually the same approach; in both cases, you are not swapping the parameters, but rather values in the objects they reference

Using an Array

static void swap(int [] arr, int index1, int index2) {	
	int t = arr[index1];
	arr[index1] = arr[index2];
	arr[index2] = t;
}

in this scenario, we are not modifying the parameters — in particular the array reference — but rather elements of the object (i.e., the array) it references

Embedding the Values to be Swapped in an Object

class Pair {
	Pair(int first, int second) {
		this.first = first;
		this.second = second;
	}
	public int first, second;	// making them public so we can get to them - not relevant to the discussion
}

Pair pair = new Pair(a, b);
swap(pair);
a = p.first;
b = p.second;	

static void swap(Pair p) {	
	int t = p.first;
	p.first - p.second;
	p.second = t;
}

again, we are not modifying the parameter (the object reference), but rather what it is referencing — instance variables of the object (i.e., the Pair) it references

Objects and Arrays May be Changed, but It's still Call-By-value

• In summary, changes made in a method to objects (class types and arrays) passed in as parameters persist after returning from the method
• This is not because of any change in parameter transmission — it's still call-by-value — but rather because of the indirection introduced by the reference variable being the actual parameter passed, while it is the referenced object that we are interested in modifying

int [] arr = {1, 2, 3};
inc(a);
…
void inc(int [] arr) {
	for i in 0; i < arr.length; i++)
	arr[i]++;
}

A Common Mistake: Modifying the Value of a Reference Parameter

• unlike primitive parameters, which 'everyone knows' can't be modified, a modification does occur, so it's natural to assume something different is happening with the parameter transmission
  • but, as we said before, it's not the parameter, rather what it references that is being modified
• references are involved here (and there is something called call-by-reference) so it's again natural to assume that the something different is happening here.

• therefore, changes made to the reference variable (the call-by-value parameter) do not persist upon returning from the method

int [] arr = {1, 2, 3};
resize(a);
…
void resize(int [] arr) {
	int [] temp = new int [arr.length * 2];
	for (int i = 0; i < arr.length; i++)
		temp[i] = arr[i];
	arr = temp;
}

The Right way

• to do this correctly, you need to return a reference to the new array as the value of the method

  int [] resize(int [] arr) {
  	int [] temp = new int [arr.length * 2];
  	for (int i = 0; i < arr.length; i++)
  		tempi] = arr[i];
  	return temp;
  }
  			

  • you can then assign the reference; in particular to the original parameter itself

    int [] arr = {1, 2, 3};
    …
    a = resize(a);
    					

  • this (i.e., assigning the method's return value to the method's paramater) is not unfamiliar, you've done the same thing whenever you've written

    s = s.substring(2, 6);
    					

    • We'll explore the relationship of this String operation to what we're doing in the array resize a bit below

C++

• call-by-value, call-by-reference, call-by-const-reference
  • C++ has true call-by-reference, where changes to the parameter affect the argument as well
    • i.e., when the method returns, the argument has the value of its parameter
      
      
      

      void f(&x) {
      	x++
      }
      						

    • this is achieved by the compiler creating a reference variable and managing the implicit referencing/dereferencing behind the scenes
      • in the above code, x is an alias of a
      • referring to x is the same thing as referring to a
  • References (rather than values) are also passed for efficiency (a single pointer rather than a massive object); in such a situation however, one may not wish for the object to be changed, hence call-by-const-reference

Generics

• a style of programming in which algorithms are written with unspecified types that are later supplied.
  • for example, one can write a sort without specifying the type of the array elements
  • similarly, one can implement just about any of the containers covered in a data structures course without referring to the type of object to be held in the container

Java

• using generic objects, e.g. ArrayList<Integer>

  ArrayList<Integer> i_aList = new ArrayList<Integer>();
  i_aList.push_back(12);
  …
  ArrayList<String> s_aList = new ArrayList<String>();
  s_aList.push_back("Hello");
  		

  • raw type — a generic class without type argument

    ArrayList alist = new ArrayList();
    			

    • generates a warning from the compiler
• using generics promotes type safety
• relatively simple definition - class and method
• type erasure
  • Generics are a compile-time notion only
    • The compiler ensures that only objects of the proper type are inserted into the generic container
  • There is still only one ArrayList class, and it has Object as its element type

C++

vector<int> i_vect;
i_vect.add(12);
…
vector<string> s_vect;
s_vect.add("Hello");
				

• The syntax is quite similar; however the semantics and runtime behavior are vastly different
  • and again, it boils down to the static (compile-time) vs dynamic (rum-time) focus of the languages
• Generics in C++ is all compile-time
• Some terminology and concepts that will arise later
  • templates
  • instantiation
  • code bloat

Polymorphism

Overloading and Overriding

Overloading (Compile-time Polymorphism)

class C {
	…
	void print(int i) {…}
	void print(String s) {…}
	…
}

• compiler (textually) resolves which method to call at point of invocation

  …
  f(3);			// print(int)
  f("Hello");		// print(String)
  f(3.5);			// ???
  f(new Integer(2));	// ???
  		

  • return type not used in resolution

    class C {
    	…
    	int print(int i) {…}
    	double print(int i) {…}
    	…
    }
    …
    int i = f(3);				// compile-time error
    double d = f(3);			// compile-time error
    System.out.println(f(3));		// compile-time error		
    				

• overloading can take place within the same class (as above) or within the inheritance hierarchy

  class C {
  	…
  	void print(int i) {…}
  	…
  }
  
  class D extends C {
  	…
  	void print(String s) {…}
  	…
  }
  		

Overriding (Run-time Polymorphsim)

class C {
	…
	void f(int i) {…}
	…
}
…
class D extends C {
	…
	void f(int i) {…}
	…
}

• Method resolution occurs at run-time and is based on the run-time type of the receiver;

  C c = new C();
  c.f();		// C.f is called
  D d = new D();
  d.f();		// D.f is called
  c = d;		// upcast (legal)
  c.f();		// D.f is called! … the receiver is a D!
  		

• compile-time vs runtime method resolution
  • f() vs f(3) detectable by compiler
  • overriding requires the signatures be identical; the resolution occurs at run time

    class Sup {
    	…
    	void f() {…}
    	…
    }
    
    class Sub extends Sup {
    	…
    	void f() {…}
    	…
    }
    
    class App {
    	…
    	Sup sup;
    	sup = new Sup();
    	sup.f();
    	sup = new Sub();
    	sup.f();
    	…
    }
    				

    
  • In both cases the compiler sees the same reference variable — sup
  • However, the actual receiver object is different for the two cases
  • The resolution of the actual method to be called must be deferred to runtime, and then method resolution begins at the object's class
• indirection required for run-time polymorphic methods (method tables)
  • i.e., the compiler cannot insert an actual method address into the object or byte code
• Java
  • polymorphism happens 'automatically'
• C++
  • polymorphism is available only under certain circumstances, and only if so declared

Maintaining Semantic Consistency

• + and +=
• << and >>
• == and != System.out and System.in ??

Leveraging Functionality

Delegation / Wrapper Methods

• methods/functions whose primary behavior is to call another method for their basic functionality are called wrapper or delegation methods
  • using this technique (i.e., of depending on another method's logic for one's own behavior) reduces redundancy, explicitly reveals the relationship between the methods, and ensures that relationship is maintained
  • we sometimes refer to the function containing the logic as the workhorse function

Example: size and isEmpty

• Simple delegation function: for a container, once size is implemented, isEmpty can be simply coded as

  class ArrayList {
  	int size() {logic to determine number of elements in the container}
  	boolean isEmpty() {return size() == 0;}
  	…
  }
  		

  • By declaring size to be abstract at the collection superclass (interface) level, we can then actually provide the above definition of isEmpty (which depends on size) at that level.

    abstract class Collection {
    	abstract int size();
    	boolean isEmpty() {return size() == 0;}	// one isEmpty implementation for all Collection (sub)classes
    	…
    }
    					

    class ArrayList extends Collection {
    	int size() {logic to determine number of elements in an ArrayList}
    	…
    }
    					

    class HashSet extends Collection {
    	int size() {logic to determine number of elements in a HashSet}
    	…
    }
    …
    					

Example: Composition of toString Methods

• Given the class:

  class Student {
  	…
  	public String toString() {return id + " " + name + "\n" + address + "\n" + courses;}
  	…
  	int id;
  	Name name;			// each of these classes has its own toString method
  	Address address;
  	ArrayList courses;
  }
  		

  the toString method leverages the toString methods of its component instance variables that are objects (class types).
  • i.e., you don't write the toString of a class from scratch; rather you use the toStrings of the class' instance variables

Example: Copy Constructors and Copy Methods

• a copy method and a copy constructor
  • if for some reason, you have need of a copy constructor and a copy method, you can usually code the copy method and then leverage it for the copy constructor, there is no need to replicate the logic in the other; i.e., one can delegate to the other (we discussed this briefly above in the section on object copying

    class C {
    	C(C c) {this.copy(c)}		// leverages / delegates to workhorse
    	void copy(C c) {			// workhorse
    		this.i = c.i;
    		this.d = c.d;
    		this.s = new String(c.s);	// deep copy, since we're in a copy method
    	}
    
    	int i;
    	double d;
    	String s;
    }
    		

Example: Immutable and Mutable Arithmetic Operators

• + and +=
  • + takes two operands and produces a new value, leaving the operands untouched
  • += takes two operands and stores the result in the first operands (the second remains untouched); the value of the expression is the first operand (containing the result of the operation)

A Related Example: Mutable and Immutable Methods of a Rational Class

class Rational {
	…
	Rational mul(Rational r) {…}		
	Rational mulInPlace(Rational r) {…}
	…
	int num, denom;
}

Rational 
	r1 = new Rational(1, 2),
	r2 = new Rational(3, 4);

Rational r3 = r1.mul(r2);	// r3 is pointing at a new Rational containing 3/8; r1 and r2 are unchanged
r1.mulInPlace(r2);		// r1 is still pointing at the same object as before, but the num/denom is now 3/8
r2 = r2.mul(r2);		// r2 is pointing at a new (different) Rational object containing 9/16

• r1.mul(r2) is like r1 * r2 (operation produces new value; operands are not modified)
• r1.mulInPlace(r2) is like r1 *= r2 (operation places result in first operand; second is untouched)

Deciding on Who Leverages Whom

• copy method can't call copy constructor; we're not interested in creating a new object, we want an in-place copy
• size can't call isEmpty

• Sometimes both becomes wrappers and a third function is introduced to act as the workhorse

Example: The Rational class again

a     c     a * c
-  *  -  =  -----
b     d     b * d

No Leveraging

mul Method

Rational mul(Rational r) {
	Rational result = new Rational(this.num * r.num, this.denom * r.denom);
	return result;
}

• Note the creation of a new Rational
• The operation preserves the original operands, i.e., they are immutable
• If all operations create new values, the class is said to be immutable

mulInPlace Method

Rational mulInPlace(Rational r) {
	this.num *= r.num;		
	this.denom *= r.denom;
	return this;
}

• Note how the receiver's instance variables are assigned the results of the multiplication
  • This is what is meant by in-place
  • If the class contains such operations, it is said to be mutable
• void would be acceptable; we return the receiver to allow chaining

  r1.mulInPlace(r2).mulInPlace(r3));		// r1 *= r2 * r3;
  		

mulInPlace Leveraging mul

• the semantics of rational multiplication is coded in the immutable method (mul);
  • as shown above in the No Leveraging section
• the in-place (mutable) method (mulInPlace) then leverages mul

  Rational mulInPlace(Rational r) {
  	Rational result = this.mul(r);
  	this.copy(result);
  	return this;
  }
  		

  
  
• note the need for an in-place copy method

  this.copy(result);
  				

  • i.e., for leveraging in this direction, we must define a copy method in the class

    Rational copy(Rational r) {
    	this.num = r.num;
    	this.denom = r.denom;
    }
    				

• also, note that garbage is created (the new value returned by mul is copied to result and then never used again

mul Leveraging mulInPlace

• the semantics of rational multiplication is coded in the in-place (mutable) method (mulInPlace);
  • as shown above in the No Leveraging section
• the immutable method (mul) then leverages mulInPlace

  Rational mul(Rational r) {
  	Rational result = new Rational(this);
  	return result.mulInPlace(r);
  }
  		

  
  • note need for a copy constructor

    Rational result = new Rational(this);
    				

  • also, note that the return value of the in-place method is the receiver itself (this), as it contains the result of the operation
  • finally, note that no garbage is created in this direction
    • In Java, this is not a big deal, but as we will see in C++, we have to avoid/handle garbage ourselves; therefore this will be our preferred direction in that language

More on mulInPlace's Return Value

• On first thought, there's no reason for mulInPlace to have a return value — the effect of the operation was to modify the receiver — r1 in the above example r1.mulInPlace(r2)
  • and, in fact, in the that example, we're 'dropping the return value on the floor', i.e., not using it
• But looking at the version of mul that leverages mulInPlace, we see that having a return value is useful:

  return result.mulInPlace(r);
  		

  as opposed to

  result.mulInPlace(r);
  return result;
  		

• this return value is useful in other contexts; in particular expressions involving many applications of mul and mulInPlace:

  r1 = r2.mul(r3.mulInPlace(r4));
  		

  which is equivalent to:

  r1 = r2 * r3 *= r4;
  		

  • As mentioned above, this technique — i.e., returning the receiver as the return value, and thus allowing it to be the receiver in subsequent call to a method of the same class — is known as chaining as it allows one to chain together sequences of calls to methods of the receiver's class.

Initialization of Variables in the Presence of Composition and Inheritance

General Philosophy

Java

• attempts to ensure all variables are initialized before use:
• Local variables must be explicitly initialized before they are used.
  • Failure to do so results in a compilation error
• Class (static) and instance variables are assigned a default value (the 'zero' value … 0, false, null), if they are not explicitly initialized.
  • Attempting to use any instance variable initialized to null result in NullPointerException

C++

• global/static data is initialized to the '0' of the type
• class types with a default constructor have that constructor called
• otherwise no attempt made to initialize anything
• special mechanism to allow superclass (base class) and composed instance variables (data members) with non-default constructors to be initialized

Composition

• Strictly speaking, composition occurs with any instance variable, including primitives, i.e., the class is composed of its instance variables.
• However, we usually restrict the term to mean instance variables of a class type.

Java

• Given the class:

  class Employee {
  	…
  
  	Name name;
  }
  		

  • Assuming there's no constructor, name defaults to null (as mentioned above), i.e., it needs to be initialized to some string before it can be used.
  • Attempting to use name prior to such initialization result in a NullPointerException …
    • … as opposed to working with uninitialized data
    • the NullPointerException means that the error occurs as soon as we try to work with name; as opposed to working with 'garbage' data which may not result in an error until much later in the code.

C++

• It's a bit more complicated because the data member might be an actual object, rather than a reference, and this will pose a problem; we'll deal with this when we get to classes and constructors in C++.

  class Employee {
  	…
  
  	Name name;		// This poses a problem of initialization 
  };
  		

  • Again, assuming no constructor — however, here, name is an actual Name object, not a reference.
    • Actual objects (as opposed to pointers) have no null value (just like there is no such thing as a null value for a primitive type in Java, (i.e., all bit patterns in a 32 bit integer are legitimate values), so there is no way for the runtime to catch the use of an object before it's initialized
    • We've thus got to make sure the designer has the ability to initialize the object before any code begins to work with it

Inheritance

• When working with a subclass/superclass relationship, the constructor of the subclass needs to be invoked; and it has to be invoked BEFORE the constructor of the subclass gets to work
  • Here is Java code that illustrates the issue:

    class Window {
    	Window(int width, int height) {
    		this.width  width;
    		this.height - height;
    	}
    	int getWidth() {return width;}
    	int getHeight() {return height;}
    
    	private int width, height;
    }
    
    class BorderedWindow extends Window {
    	Borderedwindow(boolean thinBorder, int width, int height) {
    		super(width, height);
    		if (thinBorder) {
    			borderWidth = getWidth() * .05;	// requires that width of superclass has been initialized
    			borderHeight = getHeight() * .05;
    		}
    		else {
    			borderWidth = getWidth() * .1;
    			borderHeight = getHeight() * .1;
    		}
    	}
    
    	int borderWidth, borderHeight;
    }
    		

  • The user does not directly create the superclass object Window, and thus does not interact with its constructor
    • The superclass (Window) portion is created as part of the subclass (BorderedWindow)
    • It becomes the responsibility of the subclass (BorderedWindow) to invoke the constructor of the superclass (Window)
  • The code in the superclass constructor initializes the superclass' variables
  • The code in the subclass constructor initializes the subclass' variables,
  • The subclass has access to any (public or protected) variables of the superclass, and thus the possibility exists that in its initialization of the subclass variables it may use superclass variables that haven't been initialized yet.

Java

• the subclass' (BorderedWindow)constructor invokes the superclass' (Window) using the super keyword …
• … and this invocation must be the first line of executable code in the body of the subclass' constructor

C++

• C++'s solution to this is identical to its approach for composition; again, deferred until later

Code Used in this Lecture