Git

We will provide you with every exercise as its own git repository, which gives you a few useful tools. The initial commit, i.e. the clean templates is tagged as clean.

To go back to the initial state of the template you could:

  1. Commit or stash any current progress: git stash --include-untracked
  2. Checkout the tag clean: git checkout clean
  3. Read the output of git regarding creating a new branch.

How to revert file test.cpp to template without losing your work

  1. git add test.cpp: add your test.cpp
  2. git commit -m "This is where I stopped": commit your files (with a useful message)
  3. git checkout clean -- test.cpp: check out test.cpp from tag clean, i.e. empty template
  4. Do whatever you need to do with the template here

Online repositories

If you want to create an online repository for your exercises, you can use any of the available platforms (eg github, gitlab, bitbucket...). Create an empty repository there, set it as remote for your project, and push your changes. We can help you with these steps if you are interested. Please first google how to set up a 'remote repository' as the 'origin' of your local repository.

SSH Keys

You might want these. Essentially it works like this: you have to keys. A private one, top-secret, and a public one, which is meant to be public. Using the public key the remote server can encrypt something that only the owner of the corresponding private key can decrypt. You have two things to do. First create a key pair. Look at the archlinux wiki; and then install the public key in the remote server, i.e. github, gitlab, etc. Instructions on how to do this you find in the documentation of the corresponding service.

Shortcuts

For Mac and Linux, you should have a file ~/.gitconfig. You can add (among other useful things) aliases there for convenience. You can do this by adding the following lines:

[alias]
  ai = add --interactive
  br = branch
  ci = commit
  co = checkout
  di = diff
  st = status

  gr = log --graph --full-history --all --color
  --pretty=tformat:"%x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%s%x20%x1b[33m(%an)%x1b[0m"

...or whatever your preferred shortcuts are. The last one is a nicer version of git log. If you work in Windows, good luck!

Building

For those that choose not to use an IDE (please reconsider!), from the root directory of the exercise (ie the one containing CMakeLists.txt), the command-line process for compiling should be:

  1. Create a folder and switch to it: mkdir build && cd build
  2. Generate the build system, e.g. Makefile with instruction to compile with flags suitable for debugging: cmake -DCMAKE_BUILD_TYPE=Debug ..
  3. Type make VERBOSE=1
  4. and check that the compiler flags are what you would expect (or just trust CMake to have done the right thing).
  5. Repeatedly type make to rebuild you project.

Advanced build instructions

Some of our exercises will have support for clang-tidy. You can activate this as follows:

mkdir build-tidy && cd build-tidy
CC=clang CXX=clang++ cmake -DHAS_CLANG_TIDY=1 -DCMAKE_BUILD_TYPE=Debug ..

(You can also choose Release instead of Debug.)

You might need to change the line above depending on your system, e.g. clang-6.0 instead of lang. Setting MAKE_BUILD_TYPE to Release will produce faster code, but harder to debug.

You can have multiple folders, e.g. build-debug and build-release and easily switch between running binaries optimized for debugging or runtime.

Tests

Some exercises come with a battery of unit tests. These will typically be found at a folder unittests in your build directory.

Get into a habit of testing your own code. You can also write short examples of how to use libraries and test if your understanding of how the library should work is consistent with what the authors thinks it should do. In production code this is useful to automatically test any assumptions you make about how the library work. When the library changes its behaviour you will be notified first time you run your unit-tests compiled against the new library.

Run it as ./unittest/unittest to get an idea of whether your implementation so far has any bugs. Correct unit tests are not a guarantee of correct code!