COMP6771 Multichoices Collection

Week01

Lab106: Catch2 Syntax

1.What is a TEST_CASE?

a) A TEST_CASE is a uniquely-named testing scope that must contain every test we write about our program.
b) A TEST_CASE is a fancy macro that has no effect in “real” code.
c) A TEST_CASE is a uniquely-named testing scope that will keep track of all the CHECKs and REQUIREs that pass or fail.
d) A TEST_CASE is a macro where only compile-time evaluable assertions about our code can be written.

Answer: (a)

2.What is a CHECK? In what way, if any, is it different to assert()?

a) CHECK and assert are both macros and do the exact same thing.
b) CHECK and assert are both macros, but a CHECK will evaluate an expression and report it if it’s false whereas assert will crash the program.
c) CHECK is a function that suggests a fact about our code should be true, but assert enforces it.
d) CHECK records the failure of an assertion but does nothing about it and is entirely unrelated to assert.

Answer: (b)

3.What is a REQUIRE? In what way, if any, is it different to assert()?

a) REQUIRE evaluates an expression and crashes the program if it is false but assert will report it to the user.
b) REQUIRE and assert both evaluate expressions and terminate the currently executing test if false.
c) assert and REQUIRE both evaluate expressions, but only assert has an effect if the expression is false.
d) REQUIRE evalutes an expression and if false will terminate the currently executing test and move onto the next one. It is entirely unrelated to assert.

Answer: (d)

4.What are SECTION blocks in Catch2?

a) SECTION blocks are ways to divide testing logic in TEST_CASEs. Any state changes in a SECTION are not reflected in SECTIONs at the same level.
b) SECTION blocks are a way to break up long tests and have little use other than that.
c) SECTIONs are unique testing scopes that can only contain TEST_CASEs.
d) SECTIONs are part of Behaviour Driven Development and group together SCENARIOs.

Answer: (a)

5.What goes between the parentheses in TEST_CASEs and SECTIONs?

a) The function or class name that is currently being tested.
b) A succinct and insightful description in plain language of the code under test.
c) A description that matches a similarly-worded comment directly above the TEST_CASE/SECTION.
d) A note for future readers of your code about what you were thinking at the time of writing this test.

Answer: (b)

Lab108: Constant Referencing

1.Are there any errors in this code and if so what are they?

auto i = 3;
i = 4;

a) Yes: auto is a reserved keyword
b) Yes: it is illegal to initialise a variable after it is defined.
c) Maybe: it depends on what CPU this code is run on.
d) No: assignment after initialisation is legal, even in C.

Answer: (d)

2.Are there any errors in this code and if so what are they?

const auto j = 5;
--j;

a) Yes: j is a constant integer which cannot be modified.
b) Maybe: it depends if the programmer prefers east or west const.
c) No: decrementing a constant integer creates a new one.
d) Yes: auto and const should not be mixed.

Answer: (a)

3.Are there any errors in this code and if so what are they?

auto age = 18;
auto& my_age = age;
++my_age;

a) Maybe: it depends if the code is compiled as C++98 or C++11 or higher.
b) No: my_age is a reference to age, so preincrement is perfectly legal.
c) Yes: references are inherently const and so modifying age through my_age is illegal.
d) No: my_age is a copy of age and modifying my_age has no impact on age whatsoever.

Answer: (a)

4.Are there any errors in this code and if so what are they?

auto age = 21;
const auto &my_age = age;
--my_age;

a) Yes: auto references can only be used with explicit type annotations.
b) Maybe: if this code is compiled with the “-pedantic” flag in GCC, it would be perfectly legal.
c) No: my_age is a const reference, but age is not constant, so this is fine.
d) Yes: my_age is a reference to a constant integer, which cannot be modified.

Answer: (d)

Week02

Lab201: Definitive Declarations

1.Is the line marked (*) a declaration or a definition?

int get_age(); // (*)

int main() {

}

a) Declaration
b) Definition
c) Neither
d) Both

Answer: (a) This is a declaration only since the type and name of a function are known but the body has not yet been defined.

2.Is the line marked (*) a declaration or a definiton?

int get_age();

int age = get_age(); // (*)

a) Declaration
b) Definition
c) Neither
d) Both

Answer: (d). This is both since it is a global variable definition, and every definition is also a declaration.

3.Is the line marked (*) a declaration or a definition?

int main() {
  auto age = 20; // (*)
}

a) Declaration
b) Definition
c) Neither
d) Both

Answer: (d). This is both since it is a stack-local variable definition, and every definition is also a declaration.

4.Is the line marked (*) a declaration or a definition?

int main() {
  auto age = 20;
  std::cout << age << std::endl; // (*)
}

a) Declaration
b) Definition
c) Neither
d) Both

Answer: (c). It is neither a declaration nor a definition since no names (variables or functions) are introduced.

5.Is the line marked (*) a declaration or a definition?

int get_age();

int get_age() { // (*)
  return 6771;
}

a) Declaration
b) Definition
c) Neither
d) Both

Answer: (d). It is both since it is a function definition and evey definition is also a declaration.

Lab202: Resolution Overload

1.Consider the code below:

/* 1 */ auto put(char) -> void;
/* 2 */ auto put(int) -> void;
/* 3 */ auto put(const char) -> void;
/* 4 */ auto put(char &) -> void;

put('a');

Which overload of put would be selected and why?

a) Overload 1: put was called with a char and overload 3 is just a redeclaration of overload 1.
b) Overload 2: char is implicitly promotable to int and so overload 2 is the best match.
c) Overload 3: put was called with a temporary const char.
d) Overload 4: put was called with a temporary char and temporaries preferentially bind to references.

Answer: (a). A character literal has type char. This cannot bind to char& (overload 4 is not viable) and will not bind to an int without a cast (overload 2 is not viable). For the purposes of overload resolution, const char and char are identical, so both overload 1 and 3 are viable. The reason in alternative (c) is not valid, therefore only alternative (a) can be chosen.

2.Consider the code below:

/* 1 */ auto put(char) -> void;
/* 2 */ auto put(char &) -> void;
/* 3 */ auto put(const char &) -> void;
char c = 'a';
put(c);

Which overload of put would be selected and why?

a) Overload 1: put was called with a char.
b) Overload 2: put was called with a mutable char and and references have higher priority.
c) Overload 3: put was called with a const char and const references have higher priority.
d) No overload: this call is ambiguous.

Answer: (d). A variable of type c binds equally well to overload 1 and overload 2, so the call is ambiguous.

3.Consider the code below:

/* 1 */ auto memcpy(char *dst, const char *src, int n = 0) -> void *;
/* 2 */ auto memcpy(const char *dst, char * const src) -> char *;

char *dst = /* appropriate initialisation... */;
const char *src = /* appropriate initialisation... */;

void *ptr = memcpy(dst, src);

Which overload of memcpy would be selected and why?

a) Overload 1: both overloads are equally viable but the return type of overload 1 matches ptr’s type better
b) Overload 2: has exactly two arguments and a non-bottom-level const pointer is always convertible to a bottom-level const pointer.
c) Overload 1: the first two arguments match perfectly and the default argument is used for the third.
d) Overload 2: the top-level const src argument has higher priority than the corresponding bottom-level const src in overload 1.

Answer: (c). As the alternative states, overload 1 matches the first two arguments perfectly and the compiler has a default value for the 3rd argument, so it is selected.

4.Consider the code below

/* 1 */ auto min(int(&arr)[2]) -> int;
/* 2 */ auto min(int *arr) -> int;
/* 3 */ auto min(int(&arr)[]) -> int;

auto fn(int buf[3]) -> void {
    min(buf);
}

Which overload of min would be selected and why?

a) Overload 1: though min was called with an array of length 3, 3 is close to 2, so this is the best match.
b) Overload 2: the buf argument decays to int * and so overload 2 is the best match.
c) Overload 3: neither int(&)[2] nor int * match int(&)[3] perfectly but a reference to an array of unknown length does, so this is the best match.
d) No Overload: this call is ambigous.

Answer: (b). The parameter of fn is a red-herring – even though buf is int[3], this automatically decays to int *, and so the only overload that accepts an int * in min is overload 2.

5.Consider the code below:

/* 1 */ auto sink(int i, ...);
/* 2 */ auto sink(int i, short s);
/* 3 */ auto sink(...);

auto L = std::numeric_limits<long>::max();
sink(1, L);

Which overload of sink would be selected and why?

a) Overload 1: correct number of parameters and a variadic function is preferred over a narrowing conversion from long to short
b) Overload 2: correct number of parameters and variadic functions have the lowest priority in overload resolution, so this is the only viable candidate.
c) Overload 3: by definition, a single-parameter variadic function can be called with any number and type of arguments, so it is always the best match.
d) No Overload: this call is ambigous.

Answer: (b). By definition, C-style variadic functions have the lowest priority in overload resolution, so if the compiler can choose something more specific, it will. Thus, only overload 2 will be chosen.

Lab204: Programmable Errors

1.What kind of error is first displayed in the below code?

// api.h
int rand();

// me.cpp
#include "api.h"
int rand() {
    return 42;
}

// you.cpp
int rand() {
    return 6771;
}

// client.cpp
#include "api.h"
int i = rand();

a) Compile-time error: you.cpp did not include api.h
b) Compile-time error: multiple definitions of rand().
c) Link-time error: multiple definitions of rand().
d) Logic Error: 6771 is not a random number!

Answer: (c). Functions defined in source files are by default globally visible (even without including a header file) due to backwards compatibility with C. So, there are two definitions of rand(), which is a link-time error.

2.What kind of error is first displayed in the below code?

namespace constants {
  #define N 6771  
}

int N = constants::N;

int main() {
    int ints[N] = {1, 2, 3};
}

a) Logic error: constants is a bad name for a namespace
b) Compile-time error: macros do not obey namespace rules and so int N is changed to int 6771.
c) run-time error: main does not return a value.
d) Compile-time error: N is not const and so cannot be used in ints[N].

Answer: (b). Macros (such as #define) are copied-and-pasted during the preprocessing phase of compilation and so int N = constants::N; becomes int N = constants::6771;, which is an illegal identifier. Thus, this is the first error to halt compilation.

3.What kind of error is displayed in the below code?

#include <vector>

int main() {
    std::vector<int> v;
    unsigned i;
    while (i-- > 0) {
        v.push_back(i);
    }
}

a) Link-time error: i is just a variable declaration and the real i hasn’t been defined yet.
b) Logic error: i is uninitialised and so its use is illegal.
c) Logic error: v is not used after the for-loop.
d) Run-time error: pushing back continuously to a vector can result in an “out of memory” error

Answer: (b). Programs that use uninitialised variables are ill-formed and exhibit undefined behaviour (this is also true in C). Though (d) is also a potential error, use of i is concretely a logic error.

4.What kind of error is displayed in the below code?

int main() {
    int *ptr = new int{42};

    *ptr = 6771;

    return *ptr;
}

a) Logic-error: you are only allowed to return numbers in the range [-128, 128] from main().
b) Runtime-error: new can fail allocation and throws an exception if that happens
c) Compile-time error: int{42} is invalid syntax.
d) Logic-error: programmer did not check if ptr was nullptr or not before dereferencing.

Answer: (b). Like how malloc() returns nullptr if it fails, new will throw an exception, so the programmer needs to write code that can handle that (though most don’t). (a) seems plausible, but main()’s return value being clamped is a convention rather than a hard rule.

Week03

Lab304: Reversal

Consider the following code:

#include <iostream>
#include <vector>

int main() {
	std::vector<int> temperatures = {32, 34, 33, 28, 35, 28, 34};

	for (int i = 0; i < temperatures.size(); ++i) { // (*)
		std::cout << temperatures.at(i) << " ";
	}
	std::cout << "\n";

	for (const auto &temp : temperatures) {         // (^)
		std::cout << temp << " ";
	}
	std::cout << "\n";

	for (auto iter = temperatures.cbegin(); iter != temperatures.cend(); ++iter) { // (&)
		std::cout << *iter << " ";
	}
	std::cout << "\n";
}

1.Why is the for-loop marked with an (*) potentially more unsafe than the others?

a) It is a C-style for-loop, and the index could overflow.
b) It is a C-style for-loop, and the comparison of signed vs. unsigned integers can produce surprising results.
c) It is a C-style for-loop, and this makes it inherently inferior to C++ style for-loops.
d) It is a C-style for-loop, and it is possible we go off the end of the temperatures vector.

Answer: (b). The loop variable is of type int, whereas std::vector<int>::size() returns an unsigned integer type. To do such a comparison, the compiler will implicity promote the int to an unsigned value, which can be catastrophic if the integer was negative (all integers are represented as twos-complement). In this specific code snippet that won’t happen due to temperatures having only a few elements, but in general comparison of signed and unsigned integers is a major source of bugs.

2.We want to iterate through temperatures in reverse. Which loop in this code is easiest to change and why?

a) (*): Index calculations are easy to do and most people are used to seeing index-based reverse iteration
b) (^): range for-loops and an appropriate use of std::reverse conveys our intent the best.
c) (^): all standard library containers provide reverse iterators.
d) (&): just change the cbegin and cend to rbegin and rend.

Answer: (d). The change that has the least amount of typing (and thus collateral changes) and is easiest to read is (d). (a) is painfully subjective and (b) and (c) are factually incorrect.

3.What differences, if any, are there between temperatures.begin() and temperatures.rend()?

a) An end-iterator, whether from end() or rend() is “one-past-the-end”, and so is never dereferenceable, unlike begin().
b) No difference: begin() == rend() since the beginning of a range is the end of its reversal.
c) The only difference is the type: begin() returns an iterator whereas rend() returns reverse_iterator. Everything else is the same.
d) rend() would only compare equal to begin() if temperatures was empty.

Answer: (a). begin() and rend() are completely distinct types and have different semantics. Therefore, (b), (c), and (d) cannot be the answer. (a) talks about the semantics of “end-like” iterators, so it is correct.