CISC 3142
Programming Paradigms in C++
Preliminaries

A review and examination of the following Java topics and concepts will ease the transition to programming in C++, as well as hopefully clearing things in Java as well

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
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

member 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

Does assignment involve copying the object's reference (reference semantics) or its value (value semantics)?

Aliases vs Copies

Java

Assigning a primitive results in a copy, also known as a clone (value-semantics)
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

Both copy constructor and method take a reference variable of the same class as the receiver as a parameter
Copy constructor makes the newly created object a copy of the parameter
Copy method makes the existing object a copy of the parameter
- The existing object's value is changed in-place
In both cases, this is typically achieved by memberwise copying of the fields of the source object to the destination object.

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

Other Flavors of Copy Methods in Java

C++

C++ supports reference- and value-semantics for any data type

Parameter transmission

Basic Terminology

The caller passes arguments to the method where they are received in parameters

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

The effect of modifying an object via indirection through a reference parameter is often mistaken (and referred to) as call-by-reference. There are probably two reasons for this:

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.

While it's true that the reference parameter is what supplies the indirection and thus the modification of the object, the reference itself is what is being passed and THAT is still being passed by-value (i.e., as a copy of the argument).

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;
}

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 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

Generics

generic programming

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 / static polymorphism) vs. overriding (run time / dynamic polymorphism)

Overloading (Compile-time Polymorphism)

Methods can be defined with the same name (in the same scope) as long as they differ by number and/or types of parameters.

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)

Methods within a subclass can be defined with the same name and type signature as a method in a superclass; the subclass method will be invoked when messages are passed to a subclass object (even if through a superclass variable).

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

Immutable vs Mutable

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);
						
```
    - This is the same code we saw above in relation to returning a new value from the method and assigning it to the parameter
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);
				
```

Maintaining Semantic Consistency

Semantic consistency: logically related concepts should should have the same meaning / treated the same way.

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

We can achieve semantic consistency across methods, by being disciplined in our coding. The most common way to do this is by having methods that should be semantically consistent share code. This is done by leveraging functionality

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

!!! Needs picture!!!

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
```
class C {
	C(C c) {this.copy(c)}
	void copy(C c) {
		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

rational number: a number that can be represented as the ratio of two integers; i.e., a number that can be represented using a numerator and denominator; a fraction.

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

Sometimes one has no choice:

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

However, one often has a choice as to which function is leveraged (i.e., which is the workhorse and which the wrapper):

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

Example: The `Rational` class again

The semantics of rational number multiplication is to multiply the numerators and denominators, i.e.,

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

No Leveraging

I.e., both methods perform the multiplication logic … this 'no leveraging example' is just for illustrative purposes; typically one method would leverage the other, as shown in the next two sections.

`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, and thus does not interact with its constructor
  - The superclass portion is created as part of the subclass
  - It becomes the responsibility of the subclass to invoke the constructor of the superclass
- 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' constructor invokes the superclass' 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

CISC 3142 Programming Paradigms in C++ Preliminaries

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

Java

C++

Scope and Lifetime

Scope

Java

C++

Lifetime (allocation / storage duration)

Java

C++

Categories of values, objects, variables

Java

C++

Reference and Value-semantics

Aliases vs Copies

Java

Copy Constructors and Copy Methods in Java

Other Flavors of Copy Methods in Java

C++

Parameter transmission

Basic Terminology

Call-by-Value

Java

The Problem with Swapping Two Values in Java

Swapping in Java

Using an Array

Embedding the Values to be Swapped in an Object

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

A Common Mistake: Modifying the Value of a Reference Parameter

C++

Generics

Java

C++

Polymorphism

Overloading and Overriding

Overloading (Compile-time Polymorphism)

Overriding (Run-time Polymorphsim)

Immutable vs Mutable

Maintaining Semantic Consistency

Leveraging Functionality

Delegation / Wrapper Methods

Example: size and isEmpty

Example: Composition of toString Methods

Example: Copy Constructors and Copy Methods

Example: Immutable and Mutable Arithmetic Operators

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

Deciding on Who Leverages Whom

Example: The Rational class again

No Leveraging

mul Method

mulInPlace Method

mulInPlace Leveraging mul

mul Leveraging mulInPlace

More on mulInPlace's Return Value

Initialization of Variables in the Presence of Composition and Inheritance

General Philosophy

Java

C++

Composition

Java

C++

Inheritance

Java

C++

Code Used in this Lecture

CISC 3142
Programming Paradigms in C++
Preliminaries

Example: `size` and `isEmpty`

Example: Composition of `toString` Methods

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

Example: The `Rational` class again

`mul` Method

`mulInPlace` Method

`mulInPlace` Leveraging `mul`

`mul` Leveraging `mulInPlace`

More on `mulInPlace`'s Return Value