Calling Functions and Parameter Lists

Trace the state

1. f1 is identified by its name plus its parameter type: int.
2. The argument expression 2 has type int.
3. The compiler can reserve parameter storage for x safely because the argument fits the parameter type.
4. The returned int is used to initialise z.

Call audit task

Choose one nested call and write the pipeline from innermost expression to final returned value.

Applied task

Given a function declaration, write three call sites: one exact match, one compile-time mismatch and one compiling but risky implicit conversion.

Applied task

Write two overloads with the same name and explain which one is selected by three different call sites.

Example: de-nest for clarity

This pair of examples computes the same final value, but the second form makes each produced value inspectable in a debugger and easier to discuss in review.

int f1(int){ return 5; }
int f2(int){ return 7; }

int z = f1(f2(f1(1))); // hard to read

// Clearer:
int a = f1(1);
int b = f2(a);
int z2 = f1(b);

Applied task

Trace f1(f2(f1(2))) as a sequence of produced values and parameter bindings.

Example: split side effects before the call

g() and h() both mutate i. Both increments happen, but their relative order as arguments is not something to design around.

int i = 0;
int g(){ return i++; }
int h(){ return i++; }

// Unspecified relative evaluation order of arguments:
// either g() or h() may run first; 'i' is incremented twice, order unknown.
int r = std::max(g(), h());

// Safer:
int a = g();
int b = h();
int r2 = std::max(a, b);

Applied task

Find a call with two mutating argument expressions and rewrite it so the state transitions are explicit.

Example: overload selection

The name print is not enough to identify the function. The argument type decides which parameter list is selected.

void print(int);
void print(double);
// void print(std::string_view); // uncomment to support strings

print(42);     // calls print(int)
print(3.14);   // calls print(double)
print('A');    // character promotes; likely print(int)
print("hi");  // error unless a string-compatible overload exists

Applied task

Design a small overload set and write example calls that prove each overload is selected intentionally.

Example: declaration before use

f1 can call f2 because f2 has been declared before f1 is compiled.

int f2(int); // forward declaration

int f1(int x) { // calls f2
    int y = 5;
    return f2(y);
}

int f2(int value) {
    return value + 1;
}

Example: forward declarations do not prove termination

This compiles once the functions are known to each other, but the cycle still needs a base case or a redesign that breaks the loop.

int f2(int); // forward declaration

int f1(int x) { // calls f2
    int y = 5;
    return f2(y);
}

int f2(int x) { // calls f1
    int y = 7;
    return f1(y); // without a base case, this can recurse forever
}

// Add termination conditions (base cases) or redesign to break the cycle.

Applied task

Explain the difference between a missing forward declaration error and an unbounded recursion design bug.

Example: signatures communicate intent

Each signature tells the caller something about cost, mutability and ownership.

int sum(const std::vector<int>& v);        // read-only, no copy
void append(std::vector<int>& v, int x);  // modifies caller's vector
void set_name(std::string&& s);           // consumes a temporary by move

Applied task

Take one function signature and rewrite it in three forms: read-only, mutating and consuming. Explain how the call-site meaning changes.

Example: identify problems, then refactor

The original calls compile, but they hide evaluation steps and rely on side-effecting argument expressions.

int f1(int){ return 5; }
int f2(int){ return 7; }

int i = 0;
int g(){ return i++; }
int h(){ return i++; }

int main() {
    int z = f1(f2(f1(1))); // hard to read
    int r = std::max(g(), h()); // side-effect order risk

    // Better:
    int a = f1(1);
    int b = f2(a);
    int z2 = f1(b);

    int left = g();
    int right = h();
    int r2 = std::max(left, right);
}

Applied task

Explain which refactor improves readability, which one removes an evaluation-order hazard and which variable names should be made domain-specific.

Applied task

Take one compiler error about a function call and rewrite it as a design question about caller/callee agreement.

Case 1: The accidental overload

A call to score(2.0) selects score(double) instead of score(int). Explain how you would prove which overload ran and whether the call site should change.

Case 2: The unsafe cast

A developer casts a double to int to satisfy a function call. Decide whether the cast represents a domain rule, a bug, or a missing overload.

Case 3: The unreadable nested call

A nested call chain fits on one line but hides three intermediate meanings. Decide where named intermediate values would improve traceability.

A. Match the declared parameter list

Decide which calls compile cleanly, which require conversion and which should be rejected or redesigned.

int markBand(int mark) { return mark / 10; }

double average(double total, int count) { return total / count; }

int a = markBand(72);
int b = markBand(72.5);
double c = average(180, 3);
double d = average("180", 3);

• Classify each call as exact match, conversion, mismatch or poor design.
• Explain what the compiler can protect and what the programmer must still judge.
• Rewrite the questionable calls with clearer intent.

int a = markBand(72);
int roundedMark = 73;
int b = markBand(roundedMark);
double c = average(180.0, 3);
// double d = average("180", 3); // reject: string is not a numeric total

B. Trace nested calls

Evaluate the inner call first, then bind the produced value to the next parameter.

int f1(int x) { return x + 3; }
int f2(int y) { return y * 2; }

int result = f1(f2(f1(2)));

• Write the sequence of calls in evaluation order.
• Record the value produced by each call.
• Refactor with named intermediate values if that improves readability.

const int first = f1(2);      // 5
const int second = f2(first); // 10
const int result = f1(second); // 13

C. Choose overloads deliberately

Predict which overload is selected and decide whether the call site communicates the intention.

void logValue(int value) {}
void logValue(double value) {}
void logValue(const char* value) {}

logValue(4);
logValue(4.0);
logValue("4");

• Identify the selected overload for each call.
• Explain why "4" is not the same call as 4.
• Add usage examples beside overload declarations to prevent accidental conversions.

void logCount(int value) {}
void logMeasurement(double value) {}
void logLabel(const char* value) {}

logCount(4);
logMeasurement(4.0);
logLabel("4");

D. Split side-effecting arguments

The call compiles, but the argument expressions mutate shared state. Make the order explicit before calling the function.

int i = 0;
int next(){ return i++; }

int result = combine(next(), next());

• Explain why the two calls to next() make the call-site order hard to reason about.
• Rewrite the code with named intermediate values.
• Record the expected state transitions for i before and after each statement.

int i = 0;
int next(){ return i++; }

const int first = next();
const int second = next();
const int result = combine(first, second);

E. Add the declaration before use

Repair the compile-time relationship between mutually aware functions, then check that the runtime relationship terminates.

int f1(int x) {
    return f2(x - 1); // f2 is not declared yet
}

int f2(int x) {
    return x <= 0 ? 0 : f1(x);
}

• Add the minimum forward declaration needed for compilation.
• Identify the base case that prevents unbounded recursion.
• Explain why forward declarations do not, by themselves, make recursive logic safe.

int f2(int); // forward declaration

int f1(int x) {
    return x <= 0 ? 0 : f2(x - 1);
}

int f2(int x) {
    return x <= 0 ? 0 : f1(x);
}

F. Choose the passing style

Rewrite these signatures so each one communicates whether it reads, modifies or consumes its argument.

int total(std::vector<int> values);       // copies everything
void addItem(std::vector<int> values, int item); // caller never sees the change
void rename(std::string name);             // unclear whether name is copied or consumed

• Choose by value, const&, non-const & or && for each signature.
• Explain the cost and intent trade-off for each choice.
• Add const where the function should not mutate caller-owned state.

int total(const std::vector<int>& values);       // read-only, no copy
void addItem(std::vector<int>& values, int item); // mutates caller-owned vector
void rename(std::string&& name);                  // consumes a temporary/moved string

G. Prove the call cycle terminates

Forward declarations make the functions visible to each other. They do not prove the runtime cycle is safe.

int f2(int);

int f1(int x) {
    int y = 5;
    return f2(y);
}

int f2(int x) {
    int y = 7;
    return f1(y);
}

• Identify why this can recurse forever.
• Add a decreasing measure and base case, or redesign as an iterative loop.
• State the evidence you would use to prove termination.

int f2(int);

int f1(int x) {
    if (x <= 0) return 0;
    return f2(x - 1);
}

int f2(int x) {
    if (x <= 0) return 0;
    return f1(x - 1);
}