COMP26020 – Assignment 2
Library Management Software in C++
A. Assignment
The goal of this assignment is to implement a set of C++ classes that aim to be used in a library management
software. The library holds documents of different types (novels, comics and magazines) with various attributes
(title, author, etc.) and users can borrow and return documents.
• library.h has the different classes definitions including inheritance relationships as well as the
prototypes for all classes’ methods.
• library.cpp contains the implementations of the classes.
• test-suite.cpp, catch.h, and catch.cpp implement a test suite that checks the correctness of the
library code.
The code in your repo has everything already implemented and it’s 100% functional and (mostly) correct!
Wait. What’s the point of this assignment then?
Well, the code was written by someone who only watched some of the videos in the first week and then gave up.
As such, the code is more C than modern C++, it does not use the standard library, and it does not follow any of
the C++ design approaches. Ah, and it also has a few memory leaks. This is not good C++ code.
Your actual goal is to rewrite library.{cpp,h} using the concepts and approaches we covered in the lectures.
This includes:
• RAII
• new/delete considered harmful
• C-arrays, C-strings considered redundant
• C++ standard library containers, utilities, and algorithms
• Improved type safety
• Using linters, static analyzers, and the C++ Core Guidelines to uncover errors and bad coding patterns
Your rewrite should not change the externally visible behaviour of the library classes: any possible external
function calling any of the public member functions in library.h should behave the exact same way it did before
the rewrite. In practice this means that:
a) You are allowed to edit only library.h and library.cpp
b) You are not allowed to remove existing public member functions in library.h
c) You are not allowed to change the visibility of existing member functions
d) You are not allowed to change the argument types or the return value types of public member functions
in library.h (with one exception, see below)
e) Your member functions need to return the exact same thing they would have returned originally.
On the other hand, you are free to:
a) add new member functions (private, protected, or public)
b) change the internal implementation of any member function
c) Add/remove private member variables in library.h or change their types.
The only allowed change of types in function prototypes is between types that are implicitly convertible. For
example, an int with allowed values 0/1 can be replaced by a bool. The testing code is also designed to treat all
different kinds of strings as interchangeable. If you’re not sure, test it.
B. How to approach the assignment
As is, the code is extremely unsafe. Try to use (modern) C++ capabilities that attack that problem first. If you do it
correctly, you will be able to remove large parts of the code, eliminate some warnings, and multiple guidelines
suggestions. This will make it much easier to identify any remaining issues and understand what is causing the
various warnings.
A related advice is to keep thinking about whether you actually need every piece of code in your code base. If you
can remove some function/loop/code-block without affecting the functionality of the program, remove it.
Test your code after every single change you make. Does it still compile? Does it still pass the tests? If you made a
mistake somewhere, it’s better to find out immediately rather than after another 5-10-20 changes.
Warnings from the compiler, clang-tidy and the static analyzer are often interconnected and multiple warnings are
just symptoms of the same bad design choice. In such cases, try to eliminate the actual problem, not each
symptom individually.
C. Building and testing
Test Suite
To run and test your implementation you are given a basic test suite in the form of a C++ file, test-suite.cpp. It’s
a C++ program (i.e. it contains a main function) that includes library.h. It instantiates/manipulates objects from
all the library classes and performs sanity checks. This program uses the Catch1
test framework and requires two
additional source files to be compiled: catch.cpp and catch.h. You can compile the program manually:
$ g++ -std=c++17 test-suite.cpp library.cpp catch.cpp -o test-suite
and execute the test suite with:
$ ./test-suite
You don’t need to understand the testing code fully, but if you get failed tests, it might be useful to check the code
that is associated with the failed test in order to understand what went wrong. Overall, the suite is divided into
tests cases enclosed into TEST_CASE() { ... } statements. A test case will fail when one of the
REQUIRE( ) or CHECK( ) statements it contains fails, i.e. when condition evaluates
to false.
To complete the assignment you do not need to understand the content of catch.h and catch.cpp.
Passing all tests does not mean your code is 100% correct. Your solution is 100% correct only if the public
behaviour of all public methods remains exactly the same under all possible usage scenarios2
. When marking, we
will test whether your code is correct with a special test suite containing additional cases. So, make changes
carefully. If you are not certain about some change, add your own test case to test that change or discuss it with
us in the lab.
Make
For your convenience, we provide a Makefile that can help you automate building and testing your code.
To build the whole test suite and check the library code for warnings:
$ make
To run the gcc static analyzer
$ make analyze
1 https://github.com/catchorg/Catch2
2 You can assume that input arguments are always valid though: no null pointers, number values are within valid ranges,
filenames are legal, etc.
To run the C++ core guidelines checker and parts of the clang static analyzer:
$ make guidelines
You can change the three variables at the top of the Makefile to match your setup. CXX should point to your C++
compiler. Make sure it’s one from the last 3 years, supporting C++ 17. Also, note that make analyze will only work
with g++>=10.0. Use your compiler’s static analyzer, if you’re using another compiler. TIDY chooses which clangtidy to use. The default is to use one in the system path.
Workflow options
1. Lab workstations locally
The lab Linux workstations are already setup in the exact same way as the machine where your code will be
tested. So, it’s the easiest option to use and you will be 100% certain that if your code runs correctly for you, it will
run correctly for us too.
2. Lab workstations remotely
Same advantages as above but you can connect to them from home (through VPN) or from other university
locations. You will need an ssh client, such as openssh (Linux) or PuTTY (Windows). To connect set the remote
hostname to one in the range e-10cki18001.it.manchester.ac.uk to e-10cki18060.it.manchester.ac.uk.
For example in Linux you can do:
$ ssh -Y @e-10cki18001.it.manchester.ac.uk
If the command says that it cannot find a route to the host, try a different hostname in the valid range.
3. Your own Ubuntu Installation (VM or not)
For Ubuntu 22.04 (preferred):
$ sudo apt install make g++-11 clang-tidy-12
For Ubuntu 20.04:
$ sudo apt install make g++-10 clang-tidy-12
and edit Makefile to say CXX := g++-10
With these changes you should be getting results similar to what you would get in the lab. But keep in mind that
we will not be able to help you if you run into any problems caused by differences in the setup.
4. Other systems
This is the riskiest option. We will not be able to help you with any technical issues. It’s also possible that your
system displays different behaviour than the lab workstations. For example, we have seen multiple cases where
the submission does not compile on our side because of a missing header file, but does compile on the student’s
side because their compiler indirectly included that header. So, be aware of the risks and try to test your code on a
lab workstation before submission.
The main thing to do is to install an appropriate compiler and clang-tidy. After that set CXX and TIDY in the
makefile to point to your compiler and clang-tidy respectively.
Building and running the test suite only requires a relatively modern C++ compiler so this should be easy to get
working correctly. make analyze will only work with g++ > 10.0. If you don't have access to an appropriate version,
check whether your compiler has a static analyzer you can use. make guidelines requires clang-tidy. If you're using
Visual Studio, you could use the C++ Core Check instead.
If you don't have a recent g++ or clang-tidy, consider connecting to the lab workstations and testing your code
there following the instructions above.
D. Submission
Deliverables, Submission & Deadline
There are two deliverables: the completed library.cpp and library.h files. The submission is made through
the CS Department’s Gitlab. You should have a fork of the repository named “26020-lab2-S-CPlusPlus_