Computer Labs
Four compulsory computer labs during week 3, 4, 5, 6 of study period 3. Refer to the schedule (link on the top page) for details.
You are expected to solve (most of) the lab assignments before the lab session (contact a teacher if you need help).
Sign up for the labs at sam.cs.lth.se/Labs, groups of two students.
- Assignments: Laboratory Exercises, C++ Programming.
There are code skeletons for the labs. See the lab assignments for download instructions.
| Lab | About | Notes |
|---|---|---|
| 1 | Basic C++ Programming, tools | [1,4] |
| 2 | Introduction to the Standard Library | [2] |
| 3 | Strings and Streams | |
| 4 | Standard Containers and Algorithms | [3] |
Debuggers
A debugger is an important tool when developing programs, and especially so in languages like C and C++, which do not have built-in safety nets or give detailed information when a program crashes.
Two debuggers that can be used for the labs and are mentioned in the lab instructions are lldb and gdb.
- An introduction to lldb is available at https://lldb.llvm.org/use/tutorial.html and there is a table for translating commands between lldb and gdb at https://lldb.llvm.org/use/map.html
- The gdb manual is available as a pdf and a web page.
Notes, corrections and additions
[1]: If you do the labs on a Mac with the standard XCode development tools, you need to be aware that Apple uses llvm, so the commands gcc and g++ are aliases for clang and clang++. This is not obvious, as clang and gcc are command-line compatible, so what is written about g++ also applies to clang++. See below for more info
[2]: The file words can be found in /usr/share/dict/words on the lab computers (and most Linuxes). If it is missing on your computer you can either copy it from there, or download it here.
Alternatively, on some Linux distributions (e.g., Ubuntu), the dictionary is not included in the standard base system, but is available in the packages wbritish and wamerican. The command
sudo apt-get install wbritish (or wamerican)
installs a dictionary under /usr/share/dict/words
[3] : An alternative benchmark program, using the library google benchmark. It is more or less a drop-in repacemen for nstime.cc, with the same assumptions about file and class names.
The main program is in nsbench.cc, and it should be built with cmake, using this CMakeLists.txt.
create a build directory and build it, with the typical
mkdir build & cd build cmake .. make nsbench
It will download and build the dependent library, google benchmark.
(google benchmark can also use the testing framework google test but that is disabled in the CMakeLists.txt file with the option -DBENCHMARK_ENABLE_TESTING:BOOL=OFF due to build problems). This code and CMakeLists.txt has been tested on the school Linux machines, on a Debian box and on MacOS with the compiler from XCode.)
In the git repo, nsbench and the CMakeListst.txt is on the branch google-benchmark.
[4] There was a typo in the git instructions where in one place it said gitlab.com/cs-lth-cpp/labs-edaf30.git where it should say gitlab.com/cs-lth-cpp/labs-edaf50.git. A new corrected version has been uploaded (220126)
About the lab environment
Please note that the labs are done in a Linux command line environment. The labs can also be done on Mac OS or under the Windows subsystem for linux (WSL). You will not use an integrated development environment, but run the compiler, debugger, etc. directly from the command line.
The first lab introduces the tools. If you are not familiar with working at the command line you are recommended to start early with the first lab.
A brief introduction to working at the command line (in swedish) can be found on the EDAF30 web page. (Please note that the parts of the page related to mounting your home directory are specific to the Windows computers at Campus Helsingborg and do not apply when working on your own machine.)
If you find the command line difficult or confusing, please ask. It may be unfamiliar, but it should not be a big obstacle to completing the course.
The code skeletons will be made available through git (a system for distributed version control). You do not have to use git when doing the labs, but are encouraged to do so. For those new to git, the web page for EDAF30 contains a page with links information about git (in swedish, but links to documents in english).
Doing the labs under Windows
The lab instructions are written for a Linux system, but they can be run on Windows 10 under the Windows subsystem for linux (WSL). The web page for EDAF30 contains instructions for setting up a suitable environment under Windows 10 (in swedish). The instructions assume that WSL is activated.
Doing the labs under MacOS
The labs can be done on a Mac if you have XCode (and/or the XCode command line tools) installed (with the command xcode-select --install).
There are two things to be aware of. Firstly, the debugger shipped with XCode is lldb (and not gdb). It is possible to install gdb on a mac, for instance with MacPorts or HomeBrew, but note that the program needs to be signed, which may be a bit tricky the first time.
Secondly, valgrind does work on MacOS, but is usually not available for the latest version of the operating system, as porting it takes some time. The sanitizers (see lab 1) provide similar functionality, though, and is often enough.
Also note that (unless you install the GNU compilers yourself), gcc and g++ are aliases to clang and clang++. The two compilers are command line compatible, though, so you shouldn't have any problems with that. One problem with the c++ compiler and library shipped with XCode is that it (at least some versions) does not include the leak sanitizer. To detect and locate memory leaks, either valgrind or the leak sanitizer is very valuable. Therefore it can be worth the effort to install another version of clang or gcc that includes the leak sanitizer. Options for installing a compiler include Macports and Homebrew, or building the compiler from source.
On some platforms (e.g., Macs with an arm processor) the "streamlined" leak sanitizer (-fsanitize=leak) does not work.
The leak sanitizer is also part of the address sanitizer (-fsanitize=address). If building with -fsanitize=leak does not work, try building with -fsanitize=address.
Then, you may need to enable it at run-time by settting the environment variable ASAN_OPTIONS='detect_leaks=1'.
For instance, to run the program leak with the leak sanitizer enabled, use the command line:
ASAN_OPTIONS='detect_leaks=1' ./leak