cs136l module 4.

ide/code

Remoting Access with ssh but with the remote ssh extension.

- Bottom left

Course |apps.online.cs.uwaterloo.ca

• Source

If you are going to work remotely, you will need to install extensions for your remote environment AGAIN and AFTER you have established the SSH connection.

Pro tip: From the File item in the top menu, click on Auto Save. You can thank us later :)

CSCF (the group that manages the Linux servers) has asked us to show the following warning: When using VSCode, each student should consistently use the same ubtuntu machine and also be careful about downloading extensions they discover on the VSCode marketplace. If students download extensions that use lots of resources or cause problems on the server, we will kill their process.

e.g.

The C/C++ Intellisense extensions sometimes uses a lot of memory

To stop it from doing this, open the VSCode settings (gear icon at bottom left). Then search for "memory" and click the "Remote [SSH...]" tab. Several settings related to memory will appear. Set the "C_Cpp: Max Memory" and "C_Cpp: Intelli Sense Memory Limit" to the minimum of 256. A screenshot is pasted below:

How to fix, #include error.

• Hover over error, click quick fix then, Edit , includePath , Setting .

  • Scroll down until you get to Include Path

    • This path needs to be manually set if its not in the current directory

• Right click on a function

• Go to definitions

• peek

  • If ever you want to deal with functions that are declared and used in multiple different files.

• Go to references

• There's many short-cuts, for example

  • F12 takes you to the definition of the selected C component, if it has a definition.

All in all, VS Code is an editor; it does not come packaged with a compiler needed to convert the C++ we write into an executable binary. But since we are interested in not just writing code but being able to compile and run it, we have two options:

1. Open a terminal and use the command line to compile and execute our programs.

2. Setup a compiler (and debugger) so that we can use the VS Code graphical interface.

We discuss both options below but after a discussion on different C/C++ compilers.

C/C++ Standards and Compilers

• Most major programming languages have a governing body called the Standards Committee, which decides what is allowed/disallowed in a programming language.

  • e.g.

    • C99

    • C17

    • C23

    When new standards are made. compiler developers release a new version to support the New Standard.

• Compilers

  • Microsoft Visual C/C++ Compilers

    • Comes bundled with Microsoft Visual Studio

      • But Universities shy away from this tool due to its cost and base not being linux and open-source

        • Nevertheless the compiler is popular

  • GNU Compiler Collection (gcc)

    • For the longest time, was the most commonly used compiler used by students and in academia.

    • Most Linux installations come with gcc preinstalled, or easily installed in set-up.

    • gcc is the offical compiler for the GNU and Linux systems.

    • Known for staying up to date with standards.

    • Completely free to run, copy, and change in ANY way a user might want.

  • Clang/LLVM:

    • clang compiler supports a number of languages in the C-based family of languages ( C, C++)

    • Frontend that understands the syntax of the languages it supports, and converts them to Intermediate Representation ( IR ), that the LLVM Compiler infrastructure project supports

      • By first doing this conversion, clang is able to use the full power of the LLVM project.

So, what should you use?

• In CS136, you must use clang

  • because of the unbeaten warning and error messages

• Supports faster memory error checking, using AddressSanitizer, compared to the traditional tool, valgrind, that is used with gcc is another notch in clang's favor. We will cover these two tools later in the course. Also, some argue that the gcc debugger, gdb, is slower than lldb, the debugger that comes with clang. For CS136L, we will endeavor to discuss both clang and gcc whenever possible since CS246 (the subsequent course to CS136) uses gcc (g++ to be precise as the course covers C++).

Whatever you choose, be consistent. Since different compilers behave differently !

To run:

$which clang
/bin/clang

$clang --version
Ubuntu clang version 14.0.0-1ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /bin

The first time you get around to using a new compiler, it is best to check which compiler is going to be used.

Below we use the which command to check which clang executable the shell will execute if we run the clang command.

We said that the above way to execute the compiler was the simplest of them all. Compilers support a very large variety of command-line arguments to tune the compilation process. We recommend using the following command line arguments (often called compiler flags):

clang -std=c99 -g -Wall main.c -o myprogram    

• the -std= deduces what standard to use.

• the -g option tells the compiler to generate source level debug information which is used by the debugger

• the -Wall option is a diagonistic flag read as Warn All,

  • No warning is dismissed.

• The -o is used to provide the option to provide a name for the executable to be produced.

Note that while most of the command line arguments can be supplied in any order, the -o argument uses the next argument as the name of the executable to be created.

• The reason why main.c won't compile, its because

The compiler also needs to know where cs136.h is and the command used above does not tell the compiler where it might find headers that are not part of the C library.

• We fixed it for VS Code to not error, but not the compiler !

This is fixed with the -I option followed by the path to be INCLUDED.

It is important to note that the -I compiler argument is used to specify the path that contains header (.h) files and not the actual header files. Never provide header files directly to the compiler!

So we have the updated call:

CFLAGS="-std=c99 -g -Wall -I/u2/cs136l/pub/common"
clang ${CFLAGS} main.c /u2/cs136l/pub/common/cs136.o -o myprogram

• Recall CFLAGS is a SHELL variable.

  • Remember this is not permanent !

Once again, we repeat that the order of arguments to the compiler does not matter, except for the -o argument which will use the subsequent argument as the name to use for the executable file to be created.

After compiling we just run the executable:

./myprogram

if no name is provided for the executable, by default its a.out

But what then if a.out already exists?

Compiling Via VSCode.

Additional advice: carefully read not skim the following. Failure to carefully follow all steps will likely cause issues with configuring your project.

• Go to Terminal

  • Then Run Build Task

    • Larger pieces of code have a larger build process than just compiling, we discuss these in later modules.

• 

Note that in the past CSCF, the department that manages our Linux environment, has occasionally installed clang at /bin/clang. If that happens to be the case in the term you are reading these notes, the paths shown in the screenshot would read /bin/clang rather than /usr/bin/clang. This is not important, select whichever clang path you see.

• Running it this way, will again error because you have not told it the path to get "cs136.h", we have to create a build task.

  • Click the gear icon next to the selector for the compiler to be used.

This will open a new file named tasks.json and pre-populate a configuration. This file is stored within a .vscode directory created in your project's root directory. It contains all the different tasks that have been customized. We have pasted below the default configuration that was created for us:

If you are interested, you can of course mess around with this to your heart's content. If you mess up, simply delete everything and leave the following skeleton in tasks.json:

{
    "tasks": [
    ]
}

Alternatively, if you really mess up, just delete the tasks.json file by right clicking on the file in the file explorer and selecting Delete Permanently .

• To fix our issue, we need to change our args option

  • This is the command-line arguments supplied to the command-line command that will run when we click Run Build Task

Now we configure the program.

Click Run , then Add Configuration , this will create a new JSON File called launch.json

After refreshing the file ( by going back to main.c and going back to launch.json , we click the blue Add Configuration blue button, and click C/C++: (gdb) and NOT Attach (select the second option in the screenshot not the first one).

Let's configure this configuration. For program replace the string that says "enter program name", for example ${workspaceFolder}/a.out" with ${workspaceFolder}/myprogram since we named the executable myprogram when we configured the build task. We will leave everything else as is for now. Later in the course, we will revisit this configuration to configure the debugger.

From now on, when you have made changes to your code, you would:

• Step 1: Build: click Terminal, then Run Build Task

• Step 2: Execute: click Run, then Run Without Debugging

• This too needs to be configured.

launch.json - add to configs

"preLaunchTask": "clang build file", 

What does this change do?

• It tells the launch configuration that there is a pre launch task (hence the name) that must be completed. Notice the string value assigned to preLaunchTask, clang build file is the string that we assigned to the label attribute in the task we have configured within tasks.json. The string values of label within tasks.json and the prelaunchTask within launch.json must match exactly down to the whitespace.

Once this has been configured, go ahead and press the down arrow button next to the play button in the top right view when main.c is open in the Editor. Select Run: C/C++ File. You will be likely presented with a long list of options with most of them using the gcc compiler; search for the one which says (gdb) Launch preLaunchTask: clang build file. Select this option. By telling the launch configuration that this is a pre launch task, we have forced the launch configuration to not begin until this task is complete; at which point the myprogram executable has been created. (Don't ask how we figured all of this out!)

• After this we are DONE

If you are going to use VS Code for CS136/CS136L/CS246/CS241, we highly recommend conducting all development remotely on the Linux Student Servers to ensure consistency between your development environment and Marmoset's testing environment.

We also discussed how to properly setup the IntelliSense environment so that we can leverage features such as highlighting, auto/tab completion, error reporting via squiggles, hover text, jumping to definitions/uses etc. Consistent use of the IDE, especially in bigger projects, can significantly increase developer productivity.

In the module, we also discussed popular C compilers and gave reasoning why CS136 chose to use Clang for CS136/CS136L. We also discussed how to compile and run C programs from the command line and the VS Code IDE. The latter required some painful customization of tasks and launch configurations but at least the configuration needs to be done just once.

While we have taught you how to configure the tasks and launch configurations, in our opinion, using this feature in VS Code is not worth the effort it takes to set it up. In our opinion, you are better off using the Editor features in VS Code to write code but then switching to the Terminal within VS Code to compile and run your code.

The VS Code software is an incredibly useful IDE. We have only just scratched the surface. In later modules, we will discuss how the IDE supports use of version control (e.g. through the use of a git extension) and debugging (via a visual debugger).