Skip to content
Topos Uranos
English

Compiling, running and configuring

Summary

This lesson sets the way of working that the course will follow to the end. It describes the cycle of editing, saving, compiling, running and reading, and explains why it pays for an error to be discovered at the earliest possible stage; it presents the compile command that the course recommends and what each of its options does; it shows how to carry out the cycle from the terminal and how to configure Visual Studio Code so that it compiles with the same options; it teaches how to tell an error from a warning in the compiler output and how to locate the line they refer to; it presents the sanitizers, which stop the program when it incurs certain kinds of undefined behavior and point out the line; and it leaves the console ready to display accented letters and the ñ.

Learning objectives

  1. Compile a program from the terminal with the course options (-std=c++23 -Wall -Wextra and the rest), name the executable with -o and run it.
  2. Configure Visual Studio Code so that it compiles with the same options as the terminal and shows the warnings in its Problems panel.
  3. Tell an error from a warning in the compiler output, name the option that produced each warning and locate the line it refers to.
  4. Enable the memory error and undefined behavior sanitizers, and recognize in their report the kind of fault and the line where it occurred.
  5. Diagnose why an output shows strange symbols instead of accented letters and the ñ, and configure the editor and the console so that they are displayed correctly.

The work cycle

Writing a program is not a single act, but a cycle that is repeated dozens of times in one session. It has five moments: the source code is edited; the file is saved, because the compiler reads the disk and not the editor's screen; it is compiled, that is, the compiler is asked to translate the file into an executable; the result is run; and everything the compiler and the program wrote is read carefully. What was read leads to a new edit, and the cycle begins again.

The last moment is the most neglected and the one that matters most. The premise is simple: the later a defect is discovered, the more it costs to fix. If the compiler points it out, one knows on which line and almost always why; if it shows up when the program runs, one knows only that something went wrong; if it shows up weeks later, with other data, perhaps no one will ever learn the cause. It follows that defects should be discovered as early as possible, and that the compiler should be treated as the program's first reviewer: a tireless reader that, well configured, warns of much more than typing errors.

This lesson configures that reviewer on three levels: errors, which prevent the executable from being produced; compiler warnings, which allow it, but point out suspicious code; and sanitizers, which watch the program while it runs. It assumes that the compiler and the editor are installed (lesson 1.3). The examples use variables and if statements, which will be explained in lessons 2.1 and 4.1; here it is enough to read them.