Exercises (do NOT turn in)

* Ch 3: 3.5, 3.6, 3.7 (and other interesting ones.)

Reading Assignment

* Ch 4.

Midterm 1

* Friday, July 7 (web page has been updated)

1. Important for departmental consideration if you are applying for CS/CE majors this quarter.

2. All lectures, sections, exercises, homework assignments, reading assignments up to Thursday, July 6.

Assertion

The statement

assert( i > 0 );

asserts a truth condition of a correct program.

#include <assert.h>

...

assert( i > 0 );

...

When to use assert()

1. when you can afford to terminate the program.

2. for cases that should not happen, but you want to detect them if they do happen.

3. for example, detection of program errors, useful for pre-conditions too.

int add(int n)

{ assert(n > 0); // if this is what you want...

...

}

When NOT to use assert()

1. when you cannot afford to terminate the program.

2. for cases that may happen due to normal execution of the program.

3. for example, detection of user input errors.

cin >> n;

assert(n > 0);

* The user will be mad about you when the program terminates because a wrong input.

* You should instead report the problem and give the user a second chance to type in a value for n.

Function overloading

* In C++, you can overload a function.

char* concat(char* s1, char* s2);

char* concat(char* s1, char c2);

char* concat(char c1, char* s2);

char* concat(char c1, char c2);

s3 = concat("abc", "def");

s3 = concat("abcde", `f');

s3 = concat(`a', "bcdef");

s3 = concat(`a', `b');

* The compiler will determine which function to call based on the types and order of the arguments.

* Given these 4 function prototypes,

void print();

void print(int);

void print(int, int);

void print(char*, char*, int, int);

* For each of the following function calls, which function is invoked?

print();

print(1995);

print(142, 143);

print("cse", 142, 143);

print("uw", "cse", 143, 143);

print(142, 143, 144);

Default arguments

// jar.h

class Jar_Type {

Jar_Type();

Jar_Type(int n);

...

};

// jar.cpp

Jar_Type::Jar_Type()

{ units = 0;

}

Jar_type::Jar_Type(int n)

{ units = n;

}

* can be rewritten this way:

// jar.h

class Jar_Type {

Jar_Type(int n = 0);

...

};

// jar.cpp

Jar_type::Jar_Type(int n)

{ units = n;

}

* Notice the absence of "= 0" in the definition.

Jar_Type jar1;

Jar_Type jar2(100);

Layered Software

* Software modules can make use of other (often called lower level) modules.

* A higher level module is "implemented" by the modules at the next lower level.

class New_Jar_Type {

public:

...

private:

float my_float;

Jar_Type my_jar;

};

A hierarchy diagram

How to design software layers

* Each module should be responsible for one level of detail only.

* A module should have a single purpose and should rely on features provided by lower level modules.

* Having a single purpose is sometimes referred to as having a high "degree of cohesion" - the module's functions and data are all closely related to each other.

* Lower level modules are usually more general than upper level modules - easier to reuse!

* For example, the standard libraries are good candidates of lower level modules.