This article will show you how to use Clang's front end libraries to build a simple static analysis tool which will operate on C++ source / header files. It will use the power of AST (Abstract Syntax Tree) traversal.

An abstract syntax tree is a tree structure representing the syntactical structure of code. Here is a good explanation of how it works, and here is a tool to help you explore the AST for a given piece of code.

Here, I will teach you how you can use the Clang AST to find information about the code given to it to show you how powerful it is.

This article goes through everything step by step, and I’ll explain the terminology I'm using briefly at each step.

In the first section, you'll learn how to get the open source Clang project. Then, we'll explore how you can build a static analysis tool with a simple goal: to check if each Class defined in a source / header file starts with an uppercase character. We'll do this using Clang's frontend libraries which will analyze the C++ source AST.

So go ahead and grab your favorite coding beverage, get comfortable, and read on!

Here's what we'll cover:

• Prerequisites
• How to Get the Clang Project and Access the Front-end Libraries
• How to Create the Scaffolding for the Static Analysis Tool
• Putting it All Together in Code
• Summary

Prerequisites

Before getting started, it would be beneficial to have a basic understanding of the following:

• Compilers: this page is a good primer for beginners.
• C++ : For readers not familiar with C++, Learn C++ Programming for Beginners – Free 31-Hour Course is a helpful resource.
• Git: Git Best Practices – A Guide to Version Control for Beginners is an excellent starting point.

How to Get the Clang Project and Access the Front-end Libraries

Since clang and llvm are open source projects, they have very comprehensive documentation around how to get started with getting the code and building tools using them.

You can check out the Getting Started page of the llvm project to get more information about this. I've referenced that in this article as well.

###1. Get the Clang project

On a UNIX like terminal, clone the llvm Git project into your own directory. I'll call it ast-anaylzer.

1. mkdir -p ~/ast-analyzer; cd ~/ast-analyzer
2. git clone https://github.com/llvm/llvm-project.git #Clone the llvm project source

###2. Get the CMake build system and Ninja build tool

CMake and ninja work in conjunction to form a build system. CMake generates build.ninja files, which contain commands that tell ninja how to generate output targets. We’ll get into this more a little later.

####2.1 Get and install Ninja

Here are the steps you can follow to install Ninja:

1. cd ~/ast-analyzer
2. Clone the ninja source project with this command: git clone https://github.com/martine/ninja.git
3. cd ninja
4. Checkout the release branch - this is the stable branch - with this command: git checkout release
5. python3 configure.py –bootstrap This prepares and creates a Ninja binary (configure.py –help will give you more information).
6. Install ninja with this command: sudo cp ninja /usr/local/bin. After this step, as a basic validity check, do which ninja to make sure it says /usr/local/bin/ninja.

####2.2. Get and install CMake

Here are the steps you can follow to install cmake:

1. cd ~/ast-analyzer
2. Clone the cmake project source code: git clone git://cmake.org/stage/cmake.git
3. cd cmake
4. Checkout the release branch - this is the stable branch - with this command: git checkout release.
5. Run the bootstrap script: ./bootstrap. This prepares cmake to be built and installed on your host machine.
6. Build cmake from source with this command: make.
7. Then finally install cmake: sudo make install.

Once we’ve gotten Clang, we’ll build it and configure it so we can build Clang-based tools as well.

###3. Build Clang and configure it

Create a ‘build’ directory. This is where our build.ninja/ output binaries and so on will get created:

cd ~/ast-analyzer; mkdir -p build; cd build

Now we need to generate the build.ninja file in order to build Clang and also the tools in the directory from the project cloned earlier (llvm/clang-tools-extra). You can do this using CMake like this:

cmake -G Ninja ../llvm-project/llvm -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" # Enable the clang-tools projects in our build as well

This should generate a build.ninja file, which I encourage you to open and check out the contents. You will see that it contains a list of targets followed by dependencies. For example, one of the targets may look something like this:

#############################################
# Utility command for install-llvm-headers

build install-llvm-headers: phony CMakeFiles/install-llvm-headers llvm-headers

We’ll also do this for the custom static analysis tool we build in the next steps.

###4. Build and install all targets specified in the build.ninja file

ninja; ninja install

Okay, the setup is done and now we get to the fun part!

How to Create the Scaffolding for the Static Analysis Tool

We’ll be building our tool as a part of the clang-tools-extra directory in llvm-project/clang-tools-extra. Let's go ahead and create that directory. We’ll call our tool class-analyzer.

mkdir ~/ast-analyzer/llvm-project/clang-tools-extra/class-analyzer
cd ~/ast-analyzer/llvm-project/clang-tools-extra/class-analyzer

Now we need to create a CMakeLists.txt. This is basically a file that tells the CMake build system to add the source files in this tool to the build.ninja file it will generate. This lets ninja know how to build our tool.

Our CMakeLists.txt file will look like this:

CMakeLists.txt

set(LLVM_LINK_COMPONENTS support)
set(CMAKE_CXX_COMPILER /usr/bin/clang++)  


add_clang_executable(class-analyzer
  ClassAnalzyer.cpp
  MyFrontendActionFactory.cpp
  MyFrontendAction.cpp
  MyASTConsumer.cpp
  )
target_link_libraries(class-analyzer
  PRIVATE
  clangAST
  clangFrontend
  clangTooling
  )

The first couple lines tell the build system that the compiler should be /usr/local/bin/clang++ (the one just built in the previous steps).

The next add_clang_executable section tells the build system which source files to build as a part of our executable. We'll get more into the details of what each source file does soon. It also tells defines the name of the executable for the build system. Here it is called class-analyzer since it analyzes class names.

The target_link_libraries section informs the build system about the Clang front end libraries we should be linking against. These are the libraries which really expose the power of Clang’s AST to the tool we'll build.

Clang's API documentation is a good place to start looking for hints on how we should start writing the class-analyzer tool. Another good place to start is by scanning the source code of the Clang project we cloned earlier, for other tools! [clang-tools-extra](https://github.com/llvm/llvm-project/tree/main/clang-tools-extra) has multiple examples – these have been a source of inspiration for the code written here.

So now, let's start with the code for our very first source file. This file is contains the main() function of the executable. It looks something like this:

#include "clang/Tooling/CommonOptionsParser.h"
#include "clang/Tooling/Tooling.h"

#include "MyFrontendActionFactory.h"

#include <memory>

using namespace clang::tooling;
using namespace llvm;

static llvm::cl::OptionCategory toolCategory("class-analyzer <options>");

int main(int argc, const char** argv)
{
    // Use clang's argument parser infrastructure
    // This is used for giving clang tooling the path
    // to the source files passed in to the tool.
    // It also gets the compilation database - a collection
    // of the compiler options used in the invocation of the tool
    auto argsParser = CommonOptionsParser::create(
        argc, argv, toolCategory);
    if (!expectedArgsParser) {
        llvm::errs() << argsParser.takeError();
        return -1;
    }
    CommonOptionsParser& optionsParser
        = argsParser.get();
    ClangTool tool(optionsParser.getCompilations(),
                   optionsParser.getSourcePathList());
    auto myActionFactory
        = std::make_unique<MyFrontendActionFactory>();

    return tool.run(myActionFactory.get());
}

This source file essentially creates a tool which runs a clang FrontendActionFactory. Now to understand what FrontendActionFactory does, let's take a look at Clang's documentation for it.

We see that it has a pure virtual method,

virtual std::unique_ptr<FrontendAction> create () = 0;

which returns an std::unique_ptr to a [FrontendAction](https://clang.llvm.org/doxygen/classclang_1_1FrontendAction.html) object. FrontendAction is, in its essence, a class which allows callers to perform custom actions as Clang parses the AST of a translation unit given to it. A translation unit in simple words is the combined code given to the compiler to create an object file. It contains code included through all the header files + code in a C / C++ source file

This will become clearer as we get further along in the article.

Now we come to writing our own FrontendActionFactory which you can call MyFrontendActionFactory. This is a very simple class which just overrides the create() virtual method. It looks like this:

// Header file MyFrontendActionFactory.h
#pragma once

include<clang/Tooling/Tooling.h>


class MyFrontendActionFactory : public clang::tooling::FrontendActionFactory{
    public:
    MyFrontendActionFactory();
    std::unique_ptr<clang::FrontendAction> create() override;
};                                                         

// Source file MyFrontendActionFactory.cpp

#include "MyFrontendActionFactory.h"
#include "MyFrontendAction.h"

MyFrontendActionFactory::MyFrontendActionFactory() {

}

std::unique_ptr<clang::FrontendAction> MyFrontendActionFactory::create() {
    return std::make_unique<MyFrontendAction>();
}

Since MyFrontendActionFactory::create() needs to return an std::unique_ptr to clang::FrontendAction, we'll need to create a clang::FrontendAction object.

If we look at the Clang documentation for FrontendAction, we'll be particularly interested in looking at what we can do with the AST (Abstract Syntax Tree) of the source.

We might spot the following method:

virtual std::unique_ptr< ASTConsumer >
CreateASTConsumer (CompilerInstance &CI, StringRef InFile) = 0;

This is a virtual method that a class which inherits from FrontendAction can implement. It returns an ASTConsumer which according to the documentation,

"...is an abstract interface that should be implemented by clients that read ASTs."

So, this method looks really promising if we want to create something that will let us read the Clang generated AST!

If we look at the FrontendAction documentation again, it shows us that ASTFrontend is a class that inherits from FrontendAction. We also learn that it is:

"The Abstract base class to use for AST consumer-based frontend actions."

It only has one pure virtual method: CreateASTConsumer(). This seems promising, since...we might be able to create our own ASTConsumer object.

So, we start by reading through ASTConsumer's documentation. We see that it has a virtual method

virtual void
clang::ASTConsumer::HandleTranslationUnit(ASTContext &Ctx)

where the documentation states:

"HandleTranslationUnit - This method is called when the ASTs for entire translation unit have been parsed".

This is exactly what we want. We can override this method to do interesting things with the parsed AST.

You might now be wondering – how exactly can we use the parameter passed to this function ASTContext to actually go through the AST?

There's a class in the Clang front end API which can help us here: RecursiveASTVisitor. This is a class that does a depth-first traversal of the Clang AST and visits each node. It has methods such as VisitDecl(), VisitStmt() and so on which can help us go through virtually the whole source file's AST.

It also has a method which is particularly interesting: TraverseDecl(). This method recursively traverses through all the declarations starting from the root declaration given to it.

Putting it All Together in Code

So now what we need to do is give TraverseDecl() the root declaration of our translation unit and it will traverse the entirety of it. We can define special 'hooks' which will get called as this traversal happens. One such hook is:

bool VisitRecordDecl(const clang::RecordDecl *record);

This is called each time the RecursiveASTVisitor traverses through a CXXRecordDecl – which is Clang speak for a C++ class. We'll overload this method with our own version to do something interesting: getting the C++ Class' name and seeing if it starts with an upper-case character.

Putting all this together, here's what we get:

// MyFrontendAction.h header file
#pragma once

#include <clang/Frontend/FrontendAction.h>

class MyFrontendAction : public clang::ASTFrontendAction {
    protected:
        std::unique_ptr<clang::ASTConsumer> CreateASTConsumer(clang::CompilerInstance &ci, llvm::StringRef file) override;
};    

// MyFrontendAction.cpp source file
#include "MyFrontendAction.h"
#include "MyASTConsumer.h"

std::unique_ptr<clang::ASTConsumer> MyFrontendAction::CreateASTConsumer(clang::CompilerInstance &ci, llvm::StringRef file) {
    return std::make_unique<MyASTConsumer>(ci, file);
}

//MyASTConsumer.h header file

#pragma once

#include<clang/AST/ASTConsumer.h>
#include<clang/Frontend/CompilerInstance.h>

class MyASTConsumer : public clang::ASTConsumer {

public:
    MyASTConsumer(clang::CompilerInstance &ci, llvm::StringRef file) {}
    void HandleTranslationUnit(clang::ASTContext &context) override;
};

// MyASTConsumer.cpp source file

#include <clang/AST/RecursiveASTVisitor.h>
#include "MyASTConsumer.h"

#include <iostream>

static bool isFirstLetterUpperCase(const std::string &str) {
    return str.size() != 0 && std::isupper(str[0]);
}
class MyASTVisitor : public clang::RecursiveASTVisitor<MyASTVisitor> {
    public:
    bool VisitCXXRecordDecl(const clang::RecordDecl *record) {
        std::string name = record->getNameAsString();

        if (!isFirstLetterUpperCase(name)) {
            std::cout << "Record Decl : " << name
                      <<" doesn't start with uppercase! \n";
        }

        return true;
    }
    bool TraverseDecl(clang::Decl *decl)  {
        return
           clang::RecursiveASTVisitor<MyASTVisitor>::TraverseDecl(decl);
    }
};

void MyASTConsumer::HandleTranslationUnit(clang::ASTContext &ctx) {
    clang::TranslationUnitDecl *tuDecl = ctx.getTranslationUnitDecl();
    MyASTVisitor visitor;
    visitor.TraverseDecl(tuDecl);
}

Now to build, we just do:

cd ~/ast-analyzer/build/; ninja class-analyzer

This builds the class-analyzer executable in the build/bin directory.

Now to test out the analyzer, we create a test.cpp source file:

// test.cpp
class Test {
public:
 int a;
};

class testLower {
public:
 int b;
};

int main() {
        return 0;
}

Run class-analyzer on it:

bin/class-analyzer test.cpp

The output of this command is :

Record Decl : testLower doesn't start with uppercase!

We can use a multitude of such Visit* methods such as VisitEnumDecl, VisitFunctionDecl, VisitVarDecl, and so on to get valuable information about the source file and create our own tools. Just think about any tool which runs and performs actions on code or gives suggestions to the user.

You may think that this seems like a lot of work for a small task. But think about the potential. For example, you could write a tool which automatically gives a user suggestions to improve their code style. Or you could create a tool which analyses C++ code and finds lines of code where there might be security vulnerabilities.

The possibilities are endless. Clang's front-end libraries are extremely powerful and you can build many cool projects and tools with them.

Summary

In this article, you learned how to get and use the rich collection of Clang's Front-end libraries to parse a C++ source AST. You can use these libraries to write interesting static code analysis tools.

As this article showed, one of the most important parts of the journey of exploring Clang's libraries is the art of reading the API documentation and applying it to the problems your tools aim to solve. I hope you enjoyed the article!

Before approaching the process of running your first C or C++ code on Visual Studio Code, let me guide you through the process and get it all set up based on the operating system you are using on your computer.

C and C++ compilers

For running C or C++ code, you just need to have a valid C/C++ compiler installed on your computer. If you are using a Linux operating system, then there is a high chance that it is already installed on your system. But we need to make sure that it is correctly installed.

For checking whether or not you have the compiler (GCC/G++/MinGW) installed on your system or not, you have to check the compiler version first.

Simply open your terminal and use gcc --version and g++ --version. If you get the version number, then the compiler is already installed on your system.

You can check the version using the same commands on any operating system, whether that is a Windows, Linux, or macOS-based operating system.

If you get feedback on your terminal that it does not know anything about GCC or G++, then you have to install the compiler correctly.

If you are using the most used Windows operating system, then I already have written an in-depth article showing you all the processes step-by-step on freeCodeCamp. Make sure to read the entire article first, as it also contains a complete video to provide you with complete support.

Embedded content

If you are using another operating system, and you don't have the compilers installed, then make sure to install them before proceeding.

How to Install VS Code or VS Code Insiders

You have to download Visual Studio Code directly from the official website: https://code.visualstudio.com/.

If you want, you can also install VS Code Insiders, and the same process is applicable for that as well.

Visual Studio Code Insiders is actually the "Insiders" build of Visual Studio Code, which contains all the latest features that are shipped daily. You can think of VS Code as the stable release and the VS Code Insiders as the Insiders release of that.

If you want to experience the latest updates instantly, then you might also try Visual Studio Code Insiders (I use it myself). For downloading VS Code Insiders, you can visit the official website for VS Code Insiders here: https://code.visualstudio.com/insiders/

Make sure to download the exact file for your operating system.

Download Page: VS Code

Download Page: VS Code Insiders

The installation process is pretty basic. But I am going to show you all the steps sequentially. For now, I am going to show you the installation process using VS Code Insiders, but everything you will see here is going to be exactly the same for VS Code as well.

Make sure to click the box on the "I accept the agreement " box and click on Next.

Accept the agreement and click Next

Keep everything as it is. Do not change anything from here.

Click Next

Click Next. Again, simply click Next.

Click Next

Make sure to add the checkmark (✔) on all of the boxes. Then click on Next.

Check all of the boxes, and click Next

Click on Install.

Click Install

It might take a little time to finish the installation.

Let it finish...

Click on Finish.

Click Finish

Congrats - you've successfully installed VS Code/VS Code Insiders on your system. Now, cheers! 🥂

How to Prepare VS Code/VS Code Insiders For C and C++ Code

First, open VS Code or VS Code Insiders.

Go to the Extension tab. Search for "C" or "C++" and install the first one that is already verified by Microsoft itself.

Install C/C++ extension

Also, install C/C++ Extension Pack. It should also be verified by Microsoft.

Install C/C++ Extension Pack

Then you have to search for Code Runner and install the extension as well.

Install Code Runner Extension

Now, we need to change some settings.

Change some settings

Click the gear box (It is called the Manage section), and then click Settings. Alternatively, you can also use the shortcut keys Ctrl + ,. You need to replace the Ctrl key with the Command key for Mac.

Type "Run code in terminal" and press Enter key

In the search bar, type "Run code in terminal" and press the Enter key.

Scroll down a little bit until you find Code-runner: Run In Terminal. Make sure that the box is checked (✔).

Make sure to check the box

Now you need to restart your VS Code/VS Code Insiders. Simply close and reopen the program.

How to Test Your Code

Simply open VS Code/VS Code Insiders, open any folder, and create any file with the extension .c for the C file and .cpp for the C++ file.

After writing your code, you can run the code directly using the play button you'll find in the upper right corner.

This is how you can run any C/C++ program from VS Code/Insiders

It will compile and then run the code directly. After running a code, the code runner button would be set default to run directly. So, your computer is 100% ready for compiling and running any C/C++ programming code. 😀

Conclusion

Thanks for reading the entire article. If it helps you then you can also check out other articles of mine at freeCodeCamp.

If you want to get in touch with me, then you can do so using Twitter, LinkedIn, and GitHub.

You can also SUBSCRIBE to my YouTube channel (Code With FahimFBA) if you want to learn various kinds of programming languages with a lot of practical examples regularly.

If you want to check out my highlights, then you can do so at my Polywork timeline.

You can also visit my website to learn more about me and what I'm working on.

Thanks a bunch!

Exactly – compilers are very important, and some form of a compiler exists in all programming languages.

But, what is a compiler? What do they do exactly?

This article will teach you:

1. What a compiler is with an analogy.

2. The basic history of C compilers.

Don’t worry, you don’t need programming experience to understand what a compiler is.

You just need to understand the concept first, and then if you want, you can go for the technical definition.

1. What is a Compiler? An Analogy

Photo by Tyler Lastovich from Pexels

Imagine that you are learning a language (French, Spanish, or Portuguese) and you want to know the meaning of a word or sentence.

To do that, you are going to use Google Translate.

The first step is knowing what you will type into Google Translate and checking if it is typed correctly.

The second step is choosing the language you want to convert. For many readers, it will be English.

The third and final step is just getting to know what that sentence means in English.

Essentially, you just typed in Google Translate a sentence or word you did not understand. Google Translate translated that sentence into English.

Example: nadar(Portuguese) –> swimming (English)

The same thing happens in programming.

In this case, we are using the C language.

The first step you must take is to know what you will type in the .c file and if it is typed correctly.

In this example, the file is called main.c_._

#include <stdio.h>

int main()
{
    printf("Hello World");

    return 0;
}

First step: This code will print “Hello world”\**

The second step is to compile it. It will be compiled according to the compiler you have.

gcc -o main main.c -Wall

Second step: Command to compile c code\**

The third and final step is simply getting to know the output of the program – to make sure it is running like we want.

Quick note: if you want to know what each word in the command line terminal means, please check out the “More…” section in this article!

Third step: Hello world!\**

You can see in the image below a visual explanation of the compiling process:

Comparing the compilation of a C file with the translation of words

How C Compilers Work

Photo by JÉSHOOTS\** from Pexels\**

Over the years, tech has evolved at an incredible pace. The same applies to compilers.

The C compiler has, over time, evolved into many versions.

Just like PlayStation – there is the Playstation 2, Playstation 3, Playstation 4, and so on.

The same is true for C compilers. Once it was standardized, many versions were created:

• C89/90, a version of C once standardized,

• C99 replaced C89 and C90 in 1999.

• C11 replaced C99 in 2011.

• C17 replaced C11 in 2018.

• C2X will replace C17 in 2023.

Just like with a PlayStation, each new version has new features.

Some people prefer just playing on their PlayStation2.

It’s the same with programmers. For a variety of reasons, programmers may prefer to write and debug C code with the C99 or C11.

More About Compilers

What exactly does “gcc -o main main.c -Wall” mean, that we saw in the code above? Let's break it down piece by piece.

gcc is the command that invokes the compilation process (preprocessing, compilation, assembly, and linking).

-o main indicates that the name of the executable file created by the compilation of "main.c" is going to be called "main".

main.c is the name of the file to be compiled.

The -Wall option enables compiler warnings. Compiler warnings let you know that something in your code isn't quite right.

This is similar to Grammarly. If Grammarly suggests changing a sentence, you should in most cases change it to make it clearer and more correct.

Otherwise, if you try to change something in a phrase that's already right, it can become illegible.

In the same way, if you ignore warnings in code, it can ultimately cause major bugs and your project might even fail.

What does "Standardized" mean?

So you might be wondering, what does “standardized” mean that we saw above?

Photo by Pixabay\** from Pexels\**

Let's look at it through another analogy. There are many ways to build a house. But there is a certain way that is generally both the most efficient and the safest.

Because of this, people and organizations must agree that there is a standard way of building a house.

The process of creating that standard is called standardization.

When a set of rules becomes a standard, the set of rules becomes standardized_._

This set of rules can be a law, a certificate, or just a basic convention used by workers in a certain field.

The same applies to C compilers.

It is standardization that helps people agree on how things should be done, whether it is C compilers, car components, or anything else.

Standardization can also help people agree on which version of C to use. C compilers are an example.

The C compiler has long been considered a fundamental component of software development.

As a result of the C compiler standard, developers can compile and run other people's code without worrying that their compilers will not work.

In order to create such an important building block of the industry, there must be an organization that is responsible for establishing standards

Many organizations create and manage standards. In the case of C compilers, ISO (International Organization for Standardization) manages the standards.

As long as the ISO manages future C compiler standards, programmers and companies can develop reliable software.

Wrapping Up

Thanks for reading! Now you understand:

• What a compiler is

• The basic history of C compilers

• What standardization means

Here is the GitHub repository with the code and image files I created.

The MinGW compiler is a well known and widely used software for installing GCC and G++ compilers for the C and C++ programming languages.

But many devs face difficulties when installing the compiler, so I am going to show you all the steps to do so in this article with screenshots to help you get it done.

I will be using Windows 11, but the same process is applicable for all other Windows operating systems unless you are using Windows XP (You need to change some steps in Windows XP).

If you'd like to watch the video I made on this topic as well, here it is:

Install MSYS2

Firstly we need to download an executable file from MSYS2. Go to the official website of MSYS2: https://www.msys2.org/. The website looks like below as of today.

Scroll down a little bit until you find the download button for the executable file.

Simply click on the installer button and save the installer file in any place you want.

Finish downloading the executable file. It should not take much time depending on your internet speed.

After downloading the file, we will get this executable file.

Double click on the executable file. Then click Next.

Keep the name as it is, and click Next.

Keep all this as it is, and click Next.

Give it some time to finish the installation process.

If you keep the checkmark, then the MSYS2 terminal will open once you click Finish.

I prefer to do it this way, but if you want to do the remaining tasks later, then you need to open the terminal by yourself from the start menu.

In that case, you have to click the start button > Search for MSYS2 and click on the terminal like in the following picture:

Let me assume that we have opened the MSYS2 MSYS terminal successfully.

Apply the command pacman -Syu to update the package database and the base packages.

Type Y and press the enter key if you get this type of installation prompt.

Type Y and press the enter key.

The terminal will be closed. We have to open the terminal manually and update the rest of the packages.

Click the start button.

Search the folder named MSYS2 64bit. Click on the folder to expand and get the terminal. Open the terminal by clicking MSYS2 MSYS.

Update the rest of the packages by applying the command, pacman -Su. You might need to apply the command pacman -Sy if the terminal tells you to do that.

If you get any installation prompt, then you need to type Y or y and press the enter key.

Wait a little to finish the installation.

Close the window after finishing the installation.

Install the GCC and G++ Compilers

Click the start button. Find the MSYS2 64bit folder. Click on that folder to expand it.

If you are using a 64 bit operating system like I am, then we need to use the MSYS2 MinGW x64 terminal. Click on the terminal to open that.

⚠️ But, if you are using a 32 bit operating system, then you have to use the MSYS2 MinGW x86 terminal. Then, you need to open that terminal.

As I am using a 64 bit operating system, I have opened the terminal for 64 bit. Apply the command pacman -S mingw-w64-x86_64-gcc to install the compilers.

⚠️ If you are using a 32 bit operating system, then you have to apply the command pacman -S mingw-w64-i686-gcc in your 32 bit terminal.

Wait for a little while.

Type Y or y and press the enter key if you get the installation prompts.

Give it some time to finish the installation process.

You've now finished installing the compilers.

How to Install the Debugger

If you are using a 64 bit operating system like I am, then you have to apply the command pacman -S mingw-w64-x86_64-gdb.

⚠️ If you are using a 32 bit operating system, then you have to apply the command pacman -S mingw-w64-i686-gdb in your 32 bit terminal.

If you get any installation prompt, then simply type Y or y and press the enter key.

Give it some time to finish the installation.

You can close the terminal.

How to Add the Directory to the Path of the Environment Variables

Open the file explorer.

I am assuming that you have installed the MSYS into the default directory like I have. If you used custom directories, then you need to go to the directory where you installed it.

If you are using a 64 bit operating system like I am, then go to the mingw64 folder.

⚠️ If you are using a 32 bit operating system, then go to the mingw32 folder.

We have to go to the binary folder now. Go to the bin folder.

⚠️ If you are using a 32 bit operating system, then you have to go into your mingw32 folder > bin folder.

Copy the directory.

⚠️ If you are using a 32 bit operating system, and you also installed the MSYS2 in the default directory, then your directory should be like the following:

C:\msys64\mingw32\bin

Open the Advanced System Settings. You can do that in many ways. A simple way is to simply click the start button and search for it like the below screenshot.

Click Environment Variables from the Advanced tab.

Click on Path and select that. Then click Edit.

A window will appear as below:

Click New.

A blank box will appear.

Paste the directory here.

Click OK.

Click OK.

Click OK.

If you want to get all the steps in a video, then you can watch this video as well.

Check the Install

Now it is time to check whether we have successfully installed all of the above or not.

Open the terminal / PowerShell / CMD and apply the commands serially:

For checking the GCC version:

gcc --version

For checking the G++ version:

g++ --version

For checking the GDB version:

gdb --version

Conclusion

I hope this article helps you install your compilers on the Windows operating system for C and C++ programs.

Thanks for reading the entire article. If it helps you then you can also check out other articles of mine at freeCodeCamp.

If you want to get in touch with me, then you can do so using Twitter, LinkedIn, and GitHub.

You can also SUBSCRIBE to my YouTube channel (Code With FahimFBA) if you want to learn various kinds of programming languages with a lot of practical examples regularly.

If you want to check out my highlights, then you can do so at my Polywork timeline.

You can also visit my website to learn more about me and what I'm working on.

Thanks a bunch!

One day I came across this tweet from Lari Mazza:

As a software engineer who learned Python, Ruby, JavaScript, and Clojure first, when I tried C++ it was a horror movie. I couldn't do much, and it was so counterproductive and frustrating. Maybe because I was doing everything wrong and I didn't understand types the right way.

But even though I had so many problems, I could implement a bunch of algorithms and data structures.

Now that I'm using more and more TypeScript in my day-to-day job and my side projects, I feel I'm more prepared to confront types. Actually, not confront, but use them in my favor.

This post is my attempt to help developers think more in types and understand this mental model.

Thinking in JavaScript types

If you're here, you've probably heard that TypeScript is a superset of JavaScript. If not, great, you just learned something new today. YAY!

TypeScript is a superset because any JavaScript code is valid in TypeScript, syntactically speaking. It may or may not compile depending on the TypeScript compiler configuration. But in terms of syntax, it works just fine.

This is why you can migrate JavaScript to TypeScript progressively by just replacing the .js extension with the .ts. Everything will be without type declarations (the any type), but that's another story.

Also, if you code in JavaScript - or any other programming language - you probably think in types:

• "Hm, it is a list of integers, so I'll need to filter only the even numbers and return a new list"
• "This is an object, but I just need to get this string value from the property X"
• "This function receives two parameters. Both A and B are integers and I want to sum them"

Yeah, you get the idea. We think in types. But they are just in our heads. We constantly think about them because we need to know how to handle, parse, or modify data. We need to know which methods we are allowed to use in this object type.

To give a more concrete example, imagine you want to sum the price of all products. A product object looks like this:

const product = {
  title: 'Some product',
  price: 100.00,
};

But now with a list of products:

const products = [
  {
    title: 'Product 1',
    price: 100.00,
  },
  {
    title: 'Product 2',
    price: 25.00,
  },
  {
    title: 'Product 3',
    price: 300.00,
  }
];

Ok! Now we want a function to sum all the products prices.

function sumAllPrices(products) {
  return products.reduce((sum, product) => sum + product.price, 0);
};

sumAllPrices(products); // 425

Just receive the products as the argument and reduce all product prices. JavaScript works just fine. But while building this function you start to think about the data and how to handle it properly.

The first part: products as an argument. Here you just think: "well, we're receiving a list of some objects". Yeah, in our heads the products are a list. This is why we can think of using the reduce method. It is a method from the Array prototype.

Then we can think about the object in detail. We know that the product object has a price property. And this property is a number. This is why we can do product.price and sum with the accumulator.

Recapping:

• products is a list of objects.
• As a list, we can use the reduce method, as this method is a member of the Array prototype.
• The produce object has some properties. One of them is the price, which is a number.
• As a number property, we can use it to sum with the reduce accumulator.
• We wanted to return a number, the sum of all products prices.

We are always thinking of data types, we just need to add the type annotations to make it more explicit and ask the compiler for help. Our memory is limited and the compilers are here to help us, humans.

The type system will not only make our data more consistent, but it can also provide autocompletion for data types. It knows the types, so it can show the members for the data. We will take a look at this idea later. Here I just wanted to show that we think in types in our heads.

Simples Types & Simple Uses

So we are ready to use some strongly typed programming languages like TypeScript. We simply need to explicitly add type annotations to our data structures. It's simple, right?

But sometimes it's not that easy (usually it's not easy when you come from dynamically typed languages. You feel unproductive. It feels like a battle against types). The idea here is to make this learning curve smoother and more fun.

Here we will see many examples of how to use types in TypeScript. We'll start with easy and silly examples and progressively make it more complex while designing the mental model to think in types.

As in JavaScript, TypeScript also has basic data types like number, string, boolean, null, etc. You can find all the basic data types in the TypeScript Docs.

With these units of data, we can make our programs more useful. To be more practical, let's get a simple example. A sum function.

How does it work in JavaScript?

function sum(a, b) {
  return a + b;
}

Everything ok? Good.

Now let's use it:

sum(1, 2); // 3
sum(2, 2); // 4
sum(0, 'string'); // '0string'   WTF!

The first two calls are what we expect to happen in our system. But JavaScript is very flexible, it lets us provide any value to this function.

The last call is bizarre. We can call with a string, but it will return an unexpected result. It doesn't break in development, but it will result in strange behavior in runtime.

What do we want? We want to add some constraints to the function. It will only be able to receive numbers. That way, we narrow the possibility of having unexpected behaviors. And the function return type is also a number.

function sum(a: number, b: number): number {
  return a + b;
}

Great! It was very simple. Let's call again.

sum(1, 2); // 3
sum(2, 2); // 4
sum(0, 'string'); // Argument of type '"string"' is not assignable to parameter of type 'number'.

As we type annotate our function, we provide information to the compiler to see if everything is correct. It will follow the constraints we added to the function.

So the first two calls are the same as in JavaScript. It will return the correct calculation. But in the last one we have an error in compile time. This is important. The error now happens in compile time and prevents us from shipping incorrect code to production. It says that the string type is not part of the set of values in the number type universe.

For basic types, we just need to add a colon followed by the type definition.

const isTypescript: boolean = true;
const age: number = 24;
const username: string = 'tk';

Now let's increase the challenge. Remember the product object code we wrote in JavaScript? Let's implement it again, but now with the TypeScript mindset.

Just to remember what we are talking about:

const product = {
  title: 'Some product',
  price: 100.00,
};

This is the product value. It has a title as string and the price as number. For now, this is what we need to know.

The object type would be something like this:

{ title: string, price: number }

And we use this type to annotate our function:

const product: { title: string, price: number } = {
  title: 'Some product',
  price: 100.00,
};

With this type, the compiler will know how to handle inconsistent data:

const wrongProduct: { title: string, price: number } = {
  title: 100.00, // Type 'number' is not assignable to type 'string'.
  price: 'Some product', // Type 'string' is not assignable to type 'number'.
};

Here it breaks down into two different properties:

• The title is a string and should not receive a number.
• The price is a number and should not receive a string.

The compiler helps us to catch type errors like that.

We could improve this type annotation by using a concept called Type Aliases. It's a way to create a new name for a specific type.

In our case, the product type could be:

type Product = {
  title: string;
  price: number;
};

const product: Product = {
  title: 'Some product',
  price: 100.00,
};

It's better to visualize the type, add semantics, and maybe reuse in our system.

Now that we have this product type, we can use it to type the products list. The syntax looks like this: MyType[]. In our case, Product[].

const products: Product[] = [
  {
    title: 'Product 1',
    price: 100.00,
  },
  {
    title: 'Product 2',
    price: 25.00,
  },
  {
    title: 'Product 3',
    price: 300.00,
  }
];

Now the function sumAllPrices. It will receive the product and return a number, the sum of all product prices.

function sumAllPrices(products: Product[]): number {
  return products.reduce((sum, product) => sum + product.price, 0);
};

This is very interesting. As we typed the product, when we write product., it will show the possible properties we can use. In the product type case, it will show the properties price and title.

sumAllPrices(products); // 425
sumAllPrices([]); // 0
sumAllPrices([{ title: 'Test', willFail: true }]); // Type '{ title: string; willFail: true; }' is not assignable to type 'Product'.

Passing the products will result in the value 425. An empty list will result in the value 0. And if we pass an object with a different structure - TypeScript has a structural type system and we will dig deep into this topic later - the compiler will throw a type error telling that the structure is not part of the Product type.

Structural Typing

Structural typing is a type of type compatibility. It's a way to understand the compatibility between types based on its structure: features, members, properties. Some languages have type compatibility based on the names of the types, and it's called nominal typing.

For example, in Java, even if different types have the same structure, it will throw a compile error because we are using a different type to instantiate and define a new instance.

class Person {
  String name;
}

class Client {
  String name;
}

Client c = new Person();  // compiler throws an error
Client c = new Client();  // OK!

In nominal type systems, the relevant part of a type is the name, not the structure.

TypeScript, on another hand, verifies the structural compatibility to allow or not specific data. Its type system is based on structural typing.

The same code implementation that crashes in Java, would work in TypeScript.

class Person {
  name: string;
}

class Client {
  name: string;
}

const c1: Client = new Person(); // OK!
const c2: Client = new Client(); // OK!

We want to use the Client type, and it has the property name, to point to the Person type. It also has the property type. So TypeScript will understand that both types have the same shape.

But it is not only about classes, but it works for any other "object".

const c3: Client = {
  name: 'TK'
};

This code compiles too because we have the same structure here. The TypeScript type system doesn't care about if it is a class, or an object literal if it has the same members, it will be flexible and compile.

But now we will add a third type: the Customer.

class Customer {
  name: string;
  age: number;
};

It not only has the name property, but also the age. What would happen if we instantiate a Client instance in a constant of type Customer?

const c4: Customer = new Client();

The compiler will not accept that. We want to use the Customer, that has name and age. But we are instantiating the Client that has only the name property. So it doesn't have the same shape. It will cause an error:

Property 'age' is missing in type 'Client' but required in type 'Customer'.

The other way around would work because we want Client, and Customer has all the properties (name) from Client.

const c5: Client = new Customer();

It works fine!

We can go on for enums, object literals, and any other type, but the idea here is to understand that the structure of the type is the relevant part.

Runtime and Compile time

This is a much more complex topic in programming language theory, but I wanted to give some examples to distinguish runtime from compile time.

Basically, the runtime is the execution time of a program. Imagine your backend receiving data from a frontend form page, handling this data, and saving it. Or when your frontend is requesting data from a server to render a list of Pokemons products.

Compile time is basically when the compiler is executing operations in the source code to satisfy the programming language's requirements. It can include type checking as an operation, for example.

Compile time errors in TypeScript, for example, are very related to the code that we wrote before:

• When the type is missing property: Property 'age' is missing in type 'Client' but required in type 'Customer'.
• When the type doesn't match: Type '{ title: string; willFail: true; }' is not assignable to type 'Product'.

Let's see some examples to have a better understanding.

I want to write a function to get the index of a part of the passed programming language.

function getIndexOf(language, part) {
  return language.indexOf(part);
}

It receives the language and the part that we will look for to get the index.

getIndexOf('Typescript', 'script'); // 4
getIndexOf(42, 'script'); // Uncaught TypeError: language.indexOf is not a function at getIndexOf

When passing a string, it works fine. But passing a number, we got a runtime error Uncaught TypeError. Because a number doesn't have an indexOf function, so we can't really use it.

But if we give type information to the compiler, in compile time, it will throw an error before running the code.

function getIndexOf(language: string, part: string): number {
  return language.indexOf(part);
}

Now our program knows that it will need to receive two strings and return a number. The compiler can use this information to throw errors when we get a type error... before runtime.

getIndexOf('Typescript', 'script'); // 4
getIndexOf(42, 'script'); // Argument of type '42' is not assignable to parameter of type 'string'.

Maybe, for small projects (or small functions like ours) we don't really see too much benefit.

In this case, we know that we need to pass a string, so we won't pass a number to the function. But when the codebase grows or you have many people adding code and more complexity, it's clear to me that a type system can help us a lot to get errors in compile time before shipping code to production.

At first, we need all the learning curve to understand types and all the mental models, but after a while, you'll be more used to type annotations and eventually become friends with the compiler. It would be a helper, not a yeller.

As we are learning about the basic difference between compile time and runtime, I think it's great to differentiate types from values.

All the examples I'll show here can be copied and run in the TypeScript Playground to understand the compiler and the result of the compilation process (aka the "JavaScript").

In TypeScript, we have two different universes: the value and the type spaces. The type space is where types are defined and used to enable the compiler to do all the great magic. And the value space is the values in our programs like variables, constants, functions, value literals, and things that we have in runtime.

It's good to have an understanding of this concept because in TypeScript we can't use type checking in runtime. It has a very clear separation between type checking and the compilation process.

TypeScript has the process of type checking the source code types and sees if everything is correct and consistent. And then it can compile to JavaScript.

As these two parts are separate, we can't use type checking in runtime. Only in "compile time". If you try to use a type as a value, it will throw an error: only refers to a type, but is being used as a value here.

Let's see examples of this idea.

Imagine we want to write a function called purchase where we receive a payment method and based on this method, we want to do some action. We have a credit card and a debit card. Let's define them here:

type CreditCard = {
  number: number;
  cardholder: string;
  expirationDate: Date;
  secutiryCode: number;
};

type DebitCard = {
  number: number;
  cardholder: string;
  expirationDate: Date;
  secutiryCode: number;
};

type PaymentMethod = CreditCard | DebitCard;

These types are in the Type space, so it only works in compile time. After type checking this function, the compiler removes all the types.

If you add these types in the TypeScript Playground, the output will be only a strict definition "use strict";.

The idea here is to really understand that the types live in the Type space and will not be available in the runtime. So in our function, it won't be possible to do this:

const purchase = (paymentMethod: PaymentMethod) => {
  if (paymentMethod instanceof CreditCard) {
    // purchase with credit card
  } else {
    // purchase with debit card
  }
}

In the compiler it throws an error: 'CreditCard' only refers to a type, but is being used as a value here..

The compiler knows the difference between the two spaces and that the type CreditCard lives in the Type space.

The playground is a very cool tool to see the output of your TypeScript code. If you create a new credit card object like this:

const creditCard: CreditCard = {
  number: 2093,
  cardholder: 'TK',
  expirationDate: new Date(),
  secutiryCode: 101
};

The compiler will type check it and do all the magic and then it transpiles the TypeScript code to JavaScript. And we have this:

const creditCard = {
    number: 2093,
    cardholder: 'TK',
    expirationDate: new Date(,
    secutiryCode: 101
};

The same object, but now only with the value and without the type.

Constraints & Type Narrowing

When we restrict what we can do, it’s easier to understand what we can do.

We use types as constraints to limit the bugs in your program. To understand this concept, I'm stealing an example from Lauren Tan's talk about Type Systems.

const half = x => x / 2;

How many ways does this function can fail? Imagine a number of possible inputs:

[
  null,
  undefined,
  0,
  '0',
  'TK',
  { username: 'tk' },
  [42, 3.14],
  (a, b) => a + b,
]

And what are the results for input:

half(null); // 0
half(undefined); // NaN
half(0); // 0
half('0'); // 0
half('TK'); // NaN
half({ username: 'tk' }); // NaN
half([42, 3.14]); // NaN
half((a, b) => a + b); // NaN

We have different and unexpected results here. Here it's clear that we want a number as the half function, do the calculation, and great, it's done! But sometimes we don't control the input or the codebase is big, or new/unfamiliar, and we're able to make these little mistakes.

The idea of adding constraints to our code is to narrow the possibilities of a range of types. In this case, we want to limit the input type to a number type. It's the only type that we care about to do the half calculation. With type narrowing, we again give type information to the compiler.

const half = (x: number) => x / 2;

And with this new information, if we call the function with the test cases again, we have different results:

half(null); // Argument of type 'null' is not assignable to parameter of type 'number'.
half(undefined); // Argument of type 'undefined' is not assignable to parameter of type 'number'.(
half(0); // 0
half('0'); // Argument of type '"0"' is not assignable to parameter of type 'number'.
half('TK'); // Argument of type '"TK"' is not assignable to parameter of type 'number'.
half({ username: 'tk' }); // Argument of type '{ username: string; }' is not assignable to parameter of type 'number'.
half([42, 3.14]); // Argument of type 'number[]' is not assignable to parameter of type 'number'.
half((a, b) => a + b); // Argument of type '(a: any, b: any) => any' is not assignable to parameter of type 'number'.

Basically the compiler will tell us that only the number type, in this case, the 0 value, is a valid input, it will compile, and allow to run the code. We narrow the input type and allow only the value we really want for this function.

But are other ways to narrow the types in TypeScript. Imagine we have a function that receives a parameter that can be either a string or a number.

type StringOrNumber = string | number;

function stringOrNumber(value: StringOrNumber) {}

In the function body, the compiler won't know which methods or properties we can use for this type. Is it a string or number? We only know about the value in runtime. But we can narrow the type using the typeof:

function stringOrNumber(value: StringOrNumber) {
  if (typeof value === 'string') {
    // value.
        // your ide will show you the possible methods from the string type
        // (parameter) value: string
    value
  }

  if (typeof value === 'number') {
    // value.
        // your ide will show you the possible methods from the number type
        // (parameter) value: number
    value
  }
}

With an if statement and the typeof, we can give more information to the compiler. Now it will know the specific type for each if body.

The IDE knows what to show for the specific type. In runtime, when the value is a string, it will go to the first if statement, and the compiler will infer that the type is a string: (parameter) value: string.

When the value is a number, it will go to the second if statement and the compiler will infer that a type is a number: (parameter) value: number.

The if statement can be a helper to the compiler.

Another example is when we have an optional property in an object, but in a function, we need to return a value based on this optional value.

Imagine we have this type:

type User = {
  name: string;
  address: {
    street: string;
    complement?: string;
  }
};

It's a simple User type. Let's focus on the complement property. It's optional (take a closer look at the ? symbol), which means that it can be a string or undefined.

Now we want to build a function to receive the user and get the length of the address complement. What about this?

function getComplementLength(user: User): number {
  return user.address.complement.length;
    // (property) complement?: string | undefined
  // Object is possibly 'undefined'.
}

As we see earlier, the complement can be a string or undefined. undefined doesn't really have a property called length:

Uncaught TypeError: Cannot read property 'length' of undefined

We could make something like:

function getComplementLength(user: User) {
  return user.address.complement?.length;
}

If the complement has a string value, we can call length, otherwise, it will return undefined.

So this function has two possible return types: number | undefined. But we want to ensure that we only return number. So we use a if or a ternary condition to narrow the type. It will only call .length when it has real value (or when it is not undefined).

function getComplementLength(user: User): number {
  return user.address.complement
    ? user.address.complement.length
    : 0;
}

If it is undefined, we return the minimum length: 0. Now we can use the function with the right type design with and without the complement. Without compile and runtime errors.

getComplementLength({
  name: 'TK',
  address: {
    street: 'Shinjuku Avenue'
  }
}); // 0

getComplementLength({
  name: 'TK',
  address: {
    street: 'Shinjuku Avenue',
    complement: 'A complement'
  }
}); // 12

We'll get 0 from the first function call and 12 from the second call.

With this if concept, we can also use other helpers to do the same thing. We could use the in operator to verify a property from an object, a Array.isArray to verify an array, or the instanceof for any other class type.

We could also use more advanced concepts like assertion function or type guards, but I'll leave these concepts to future posts.

One thing that I want to dig deep in this Constraints topic is immutability.

In JavaScript and TypeScript, we have the idea of mutable objects. If you define value in a variable, we can reassign it with another value later.

let email = 'harry.potter@mail.com';
email // 'harry.potter@mail.com'
email = 'hermione.granger@mail.com';
email // 'hermione.granger@mail.com'

Now imagine you have a list of numbers. And you want to use a function to sum all of its numbers. The function looks like this:

function sumNumbers(numbers: number[]) {
  let sum = 0;
  let num = numbers.pop();

  while (num !== undefined) {
    sum += num;
    num = numbers.pop();
  }

  return sum;
}

You call the function passing your list and get the result. It works just fine.

const list = [1, 2, 3, 4];
sumNumbers(list); // 10

But what happened to your list? Did the function mutate it entirely?

list; // []

If we use the list, it's empty now. The pop in the sumNumbers function is a "mutate" function. It gets the references and removes the item from them. It's not a copy, it's the real reference.

In runtime, we can use other functions or ways to do the same thing: using reduce, do a for loop without the need to pop items from the array.

But using TypeScript, we can provide immutability in compile time. If you are not using types, it's possible to use a type assertion as const. Imagine this:

const author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
};

author.books.push({
  title: 'Steve Jobs',
  price: 10.00
});

Just an author object and then we add a new book to this author. The push method updates the book's array reference. It's a "mutate" method. Let's see if you use the const assertion as const:

const author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
} as const;

author.books.push({
  title: 'Steve Jobs',
  price: 10.00
});
// Property 'push' does not exist on type
// 'readonly [{ readonly title: "Leonardo Da Vinci"; readonly price: 50; }]'

The compiler won't compile. It gets an error on the author's object. It's is now readonly, and as a readonly object, it has no method called push (or any "mutate" method).

We added a constraint to the author's object. Before it was a specific type (with all the "mutate" methods), and now we narrowed the type to be almost the same, but without the "mutate" methods. Type narrowing.

To continue, let's add types to this object. The book and the author:

type Book = {
  title: string;
  price: number;
};

type Author = {
  name: string;
  email: string;
  books: Book[];
};

Add the type to the author object:

const author: Author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
};

Add the type to a new book object:

const book: Book = {
  title: 'Steve Jobs',
  price: 30
};

And now we can add the new book to the author:

author.name = 'TK';
author.books.push(book);

It works just fine!

I want to show another way to add immutability in compile time. TypeScript has a utility type called Readonly.

You can add the readonly for each property in an object. Something like this:

type Book = {
  readonly title: string;
  readonly price: number;
};

But it can be very repetitive. So we can use the Readonly utility to add the readonly to all properties of an object:

type Book = Readonly<{
  title: string;
  price: number;
}>;

One thing to keep in mind is that it doesn't add the readonly for nested properties. For example, if we add the Readonly to the Author type, it won't add the readonly to the Book type too.

type Author = Readonly<{
  name: string;
  email: string;
  books: Book[];
}>;

All the properties from the author can't be reassigned, but you can mutate the books list here (push, pop, ...) because the Book[] is not readonly. Let's see it.

const author: Author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
};

const book: Book = {
  title: 'Steve Jobs',
  price: 30
};

author.books.push(book);
author.books;
/* =>
 *
 * [
 *   {
 *     title: 'Leonardo Da Vinci',
 *     price: 50.00,
 *   },
 *   {
 *    title: 'Steve Jobs',
 *    price: 30
 *   }
 * ]
 *
 */

The push will work just fine.

So, how do we enforce a readonly to the books? We need to make sure that the array is a readonly type. We can use the Readonly, or use another utility from TypeScript called ReadonlyArray. Let's see the two ways to do it.

With Readonly:

type Author = Readonly<{
  name: string;
  email: string;
  books: Readonly<Book[]>;
}>;

With ReadonlyArray:

type Author = Readonly<{
  name: string;
  email: string;
  books: ReadonlyArray<Book>;
}>;

For me, both work great! But in my opinion, ReadonlyArray is more semantic and I also feel it is less verbose (not that the Readonly with an array is).

What happened if we try to mutate the author object now?

author.name = 'TK'; // Cannot assign to 'name' because it is a read-only property.
author.books.push(book); // Property 'push' does not exist on type 'readonly [{ readonly title: "Leonardo Da Vinci"; readonly price: 50; }]'.

Great! Now we can catch mutable operations in compile time. This is a way to use the concept of adding constraints to our types to make sure they only do what is really needed.

Semantics & Readability

At first, I felt that TypeScript could be very verbose because of the types and make the code much more complex than it should be. And it actually can. Strive for simplicity is the goal and it is difficult at the same time.

This idea is very related to clean code and how we can write code to be human-readable and maintainable. TypeScript is no different. Most of the cases, we don't need super complex types. Let the simple types do the work.

Another thing that I find very useful is semantic of types.

Imagine you need to add a string to the sessionStorage to save it in the browser. Your function looks like this:

function saveMyString(value: string): any {
  sessionStorage.myString = value;
}

You add a type annotation to the string input and as you don't know about the returning type, you probably add a any type.

But what's the real meaning behind this returning type? Is it returning anything?

It just saves the string to the sessionStorage. It doesn't return anything. The void type was what you're looking for. As TypeScript docs says: the absence of having any type at all.

function saveMyString(value: string): void {
  sessionStorage.myString = value;
}

Great, the meaning of the type is correct now. The correctness is very important in a type system. It's a way to model our data, but also help maintain systems for future developers. Even if the developer is ... you!

Before we were talking about verbose code. And we can improve a lot of our code by using TypeScript type inference.

For some code, we don't need to explicitly add type annotation. The TypeScript compiler will understand and infer it implicitly. For example:

const num: number = 1;

This code is redundant. We can just let the compiler infers it like this:

const num = 1;

In our example earlier, we add the annotation void to the saveMyString function. But as the function doesn't return any value, the compiler will infer that the returning type is void implicitly.

When I learned this, I thought with myself. But one of the biggest advantages of using TypeScript (or any other type system / static type language) is types as documentation. If we let the compiler infer most of the types, we won't have the documentation we want.

But if you hover over the TypeScript code in your editor (at least VS Code works like that), you can see the type information and relevant documentation.

Let's see other examples of redundant code and make the code less verbose and let the compiler works for us.

function sum(a: number, b: number): number {
  return a + b;
};

We don't need the returning type number, because the compiler knows that a number + another number is equal to a number type, and it is the returning type. It can be:

function sum(a: number, b: number) {
  return a + b;
};

Implicit code, but with documentation, and the compiler does the work.

Type inference works for methods too:

function squareAll(numbers: number[]): number[] {
  return numbers.map(number => number * number);
};

This function gets a list of numbers and makes every number a squared value. The returning type is number[], even though the result of a map is always a list, and as we have a list of numbers, it will always be a list of numbers. So we let the compiler infers this too:

function squareAll(numbers: number[]) {
  return numbers.map(number => number * number);
};

This works the same way for objects too.

const person: { name: string, age: number } = {
  name: 'TK',
  age: 24
};

A person object with a string name and a number age. But as we are assigning these values, the compiler can infer these types.

const person = {
  name: 'TK',
  age: 24
};

If you hover the person, you get this:

const person: {
  name: string;
  age: number;
}

The types are documented here.

Another benefit of type inference is that we can easily refactor our code. It's a simple example, but good to illustrate the refactoring process. Let's get the sum function again.

function sum(a: number, b: number): number {
  return a + b;
};

Instead of returning the sum number, we want to return "Sum: {a + b}". So for a = 1 and b = 2, we have the resulting string as "Sum: 3".

function sum(a: number, b: number): string {
  return `Sum: ${a + b}`;
};

sum(1, 2); // Sum: 3

Great! But now letting the compiler infers this.

// function sum(a: number, b: number): number
function sum(a: number, b: number) {
  return a + b;
};

// function sum(a: number, b: number): string
function sum(a: number, b: number) {
  return `Sum: ${a + b}`;
};

We just need to modify the returning value and the type inference will work. No need to think about the returning type. This is a small example, but for more complex functions, it would work too.

Back to the readability part, we can use Enum. A utility that defines a set of named constants. It's a way to give more meaning to the data in your application.

In your node app or a frontend app, you possibly do some fetching to request data. You commonly use a fetch object to perform a request and sometimes you need to pass the accept headers.

fetch('/pokemons', {
  headers: {
    Accept: 'application/json'
  }
});

fetch('/harry-potter/spells', {
  headers: {
    Accept: 'application/json'
  }
});

It's good, but we can also use an enum to separate this accept string in a constant and reuse.

enum MediaTypes {
  JSON = 'application/json'
}

fetch('/pokemons', {
  headers: {
    Accept: MediaTypes.JSON
  }
});

fetch('/harry-potter/spells', {
  headers: {
    Accept: MediaTypes.JSON
  }
});

And we are able to add more data related to the MediaTypes like PDF:

enum MediaTypes {
  JSON = 'application/json',
  PDF = 'application/pdf'
}

With Enum, we can encapsulate data into a meaningful block of code.

Recently, I was implementing a "state" React component. It's basically a component that renders an empty state or an error state based on the request response.

The UI for the empty and the error states were very similar. Only the title and the description text and the image icon were different. So I thought: "I have two ways in my mind to implement this: do the logic outside the component and pass all the information needed or pass a 'state type' and let the component render the correct icon and messages."

So I built an enum:

export enum StateTypes {
  Empty = 'Empty',
  Error = 'Error'
};

And I could just pass this data to the component as the type:

import ComponentState, { StateTypes } from './ComponentState';

<ComponentState type={StateTypes.Empty} />
<ComponentState type={StateTypes.Error} />

In the component, it had a state object with all the information related to the title, description, and icon.

const stateInfo = {
  Empty: {
    title: messages.emptyTitle,
    description: messages.emptyDescription,
    icon: EmptyIcon,
  },
  Error: {
    title: messages.errorTitle,
    description: messages.errorDescription,
    icon: ErrorIcon,
  },
};

So I could just receive the type based on the enum and use this stateInfo object with the State component from our design system:

export const ComponentState = ({ type }) => (
  <State
    title={stateInfo[type].title}
    subtitle={stateInfo[type].subtitle}
    icon={stateInfo[type].icon}
  />
);

This is a way to use an enum to encapsulate important data into a meaningful block of code in your application.

Another cool feature from TypeScript is optional properties. When we have properties from an object that can be a real value or undefined, we use an optional property to be explicitly that the property can be or not be there. The syntax for this is a simple ? operator in the object property. Imagine this function:

function sumAll(a: number, b: number, c: number) {
  return a + b + c;
}

But now the c value is optional:

function sumAll(a: number, b: number, c?: number) {
  return a + b + c;
}

We add the ? after c. But now we have a compiler error saying:

(parameter) c: number | undefined
Object is possibly 'undefined'.

We can't sum an undefined value (well, actually in JavaScript we can, but we receive a NaN value).

We need to ensure that the c exists. Type narrowing!

function sumAll(a: number, b: number, c?: number) {
  if (c) {
    return a + b + c;
  }

  return a + b;
}

If the c exists, it will be a number and we can sum all. If not, sum only the a and b values.

An interesting part of this optional property is that it is a undefined not null. This is why we do this, we get a compile error:

let number = null;
sumAll(1, 2, number);
// Argument of type 'null' is not assignable to parameter of type 'number | undefined'.

As the ? operator doesn't handle the null value, choose to use the undefined type in your application and so you can still use the optional property and make the types consistent. We can use it like this:

let value: number | undefined;
sumAll(1, 2, value); // 3

If you add a default value to the parameter, you won't need the ? operator. Actually, the compiler will say that the Parameter cannot have question mark and initializer.

function sumAll(a: number, b: number, c: number = 3) {
  return a + b + c;
}

Optional properties not only works on variables and parameters, but also in objects.

An API response is a good example of type definition and optional property together. In API responses, data can be optional. Sometimes the API sends, sometimes it has no value.

How we model our types is really important for an application. If an optional property is defined as a required type, we can make our application breaks in runtime. But if we design the types correctly, we have the possible errors in compile time.

Imagine we are fetching a user data and this is the way we modeled the response type:

type UserResponse = {
  name: string;
  email: string;
  username: string;
  age: number;
  isActive: boolean;
};

But in reality, the email is optional for the user. The API endpoint could return or not. But the UserResponse type we built treat it as a required property.

After fetching the user data, we want to see if the user email matches with a specific domain.

function matchDomain(email: string) {
  return email.endsWith(domain);
}

As the email property is required in the UserResponse type, the email parameter will also be required in the matchDomain function.

This is the runtime we can get if the email is undefined:

// Uncaught TypeError: Cannot read property 'endsWith' of undefined

But what would happen if we modeled the UserResponse correctly?

type UserResponse = {
  name: string;
  email?: string;
  username: string;
  age: number;
  isActive: boolean;
};

Now the email is possibly undefined and it is explicit.

But if we still keep the function matchDomain the same way, we get a compile error:

// Argument of type 'undefined' is not assignable to parameter of type 'string'.

And this is great! Now we can fix the email parameter in this function using the ? operator:

function matchDomain(email?: string) {
  return email.endsWith('email.com');
}

But now we get a compile error when running email.endsWith, because it could be undefined too:

// (parameter) email: string | undefined
// Object is possibly 'undefined'.

Type narrowing! We use an if block to return a false when the email is undefined. And run endsWith method only if the email is really a string:

function matchDomain(email?: string) {
  if (!email) return false;
  return email.endsWith('email.com');
}

It's pretty nice when we can get runtime errors in compile time. Better to code than debugging after we ship in production, isn't it?

Type composition

Type composition is very useful when trying to reuse existing types for new places of the codebase. We don't need to rewrite new types, we can create a new type by composing existing ones.

One example of composition I always have to handle using Redux or the useReducer hook from React is the idea of "reducers". A reducer can always receive a number of different actions.

In this context, actions are objects with at least a type property. It looks like this:

enum ActionTypes {
  FETCH = 'FETCH'
}

type FetchAction = {
  type: typeof ActionTypes.FETCH;
};

const fetchAction: FetchAction = {
  type: ActionTypes.FETCH
};

A fetchAction has a type FetchAction that has a property type that is a typeof FETCH.

But a reducer can receive other actions too. For example a submit action:

enum ActionTypes {
  FETCH = 'FETCH',
  SUBMIT = 'SUBMIT'
}

type SubmitAction = {
  type: typeof ActionTypes.SUBMIT;
};

const submitAction: SubmitAction = {
  type: ActionTypes.SUBMIT
};

For a specific container, we can compose all these actions into just one type and use it for the reducer parameter type.

It would look like this:

type Actions = FetchAction | SubmitAction;

function reducer(state, action: Actions) {
  switch (action.type) {
    case ActionTypes.FETCH:
    // fetching action
    case ActionTypes.SUBMIT:
    // submiting action
  }
}

All the possible actions are the Actions type. And we use a union type to "join" all action types. The action in the reducer can have the FetchAction or the SubmitAction.

As a Potterhead, I couldn't miss a Harry Potter example. I want to build a simple function to choose a Hogwarts House based on the person trait. Let's start with the houses first.

type House = {
  name: string;
  traits: string[];
}

const gryffindor: House = {
  name: 'Gryffindor',
  traits: ['courage', 'bravery']
};

const slytherin: House = {
  name: 'Slytherin',
  traits: ['ambition', 'leadership']
};

const ravenclaw: House = {
  name: 'Ravenclaw',
  traits: ['intelligence', 'learning']
};

const hufflepuff: House = {
  name: 'Hufflepuff',
  traits: ['hard work', 'patience']
};

const houses: House[] = [
  gryffindor,
  slytherin,
  ravenclaw,
  hufflepuff
];

I want to keep it simple, so the House type has only the name and the traits, a list of possible traits from people related to the house.

And then, I create each house and added all of them to the houses list.

Great! Now I'll build the Person type. A person can be a witch or a muggle.

type Witch = {
  name: string;
  trait: string;
    magicFamily: string;
}

type Muggle = {
  name: string;
    trait: string;
  email: string;
}

And this is the part we combine these two different types using the union type:

type Person = Muggle | Witch;

Using the intersection type, the Person type has all properties from Muggle or all from Witch.

So now, if I create a Muggle, I need just the name, the trait, and the email:

const hermione: Muggle = {
  name: 'Hermione Granger',
    trait: 'bravery',
  email: 'hermione@mail.com'
};

If I create a Witch, I need the name, the trait, and the magic family name:

const harry: Witch = {
  name: 'Harry Potter',
  trait: 'courage',
  magicFamily: 'Potter'
};

And if I create a Person, I need at least the name and the trait properties from Muggle and Witch:

const tk: Person = {
  name: 'TK',
  email: 'tk@mail.com',
  trait: 'learning',
  magicFamily: 'Kinoshita'
};

The chooseHouse is very simple. We just pas the houses and the person. Based on the person trait, the function will return the chosen house:

function chooseHouse(houses: House[], person: Person) {
  return houses.find((house) => house.traits.includes(person.trait))
}

And applying all the people we created:

chooseHouse(houses, harry); // { name: 'Gryffindor', traits: ['courage', 'bravery'] }
chooseHouse(houses, hermione); // { name: 'Gryffindor', traits: ['courage', 'bravery'] }
chooseHouse(houses, tk); // { name: 'Ravenclaw', traits: ['intelligence', 'learning'] }

Nice!

The intersection type is a bit different, but it can also be used to combine existing types.

When I was implementing a web app to apply my studies on UX, I needed to create a prop type for the Image component.

I had the type ImageUrl from the product type:

type ImageUrl = {
  imageUrl: string;
};

And the ImageAttr to represent all the attributes for the image:

type ImageAttr = {
  imageAlt: string;
  width?: string
};

But the props expected all this information in the component. Intersection type for the rescue!

type ImageProps = ImageUrl & ImageAttr;

Simple as that. So now, the component needs all these properties. The type looks like this:

type ImageProps = {
  imageUrl: string;
  imageAlt: string;
  width?: string
};

And we can use this type this way:

const imageProps: ImageProps = {
  imageUrl: 'www.image.com',
  imageAlt: 'an image',
};

const imagePropsWithWidth: ImageProps = {
  imageUrl: 'www.image.com',
  imageAlt: 'an image',
  width: '100%'
};

Nice! One more concept to reuse and compose types.

I also find the Pick type very interesting and useful. We have other interesting types that we could write here, but the idea here is to understand that we can compose type and there is no limit to reuse types. If you're interested in study other types, take a look at this post I wrote: TypeScript Learnings: Interesting Types.

Tooling

When you npm install typescript, you don't just get the compiler, you get the language service API, a standalone server called tsserver that editors can run to provide autocompletion, go-to, and other cool features.

These features are what some people from the TypeScript team call developer productivity tools like smart errors when type checking and IntelliSense (code completion, hover info, signature information). We look at these features throughout the whole article, but I want to make a special topic to talk about it.

The TypeScript type checker is powerful in the sense that it can infer types and provide information to some possible issues. Example: It inferred that the city is a string. And the uppercase is used the wrong way. As it knows it is a string, it also tries to find a possible method that the engineer is looking for.

const city = 'Tokyo';
city.toUppercase();
// Property 'toUppercase' does not exist on type
// 'string'. Did you mean 'toUpperCase'?

In this case, the compiler is really smart, because it finds exatcly what we wanted.

It also works for objects:

const people = [
  { name: 'TK', age: 24 },
  { name: 'Kaio', age: 12 },
  { name: 'Kazumi', age: 31 },
];

for (const person of people) {
  console.log(person.agi);
  // Property 'agi' does not exist on type '{ name: string; age: number; }'
}

With the static types, the tooling can provide a great developer experience with code completion, hover info to show defined types, and signature information for methods and other data.

If you type: 'TK'., the editor will show all the possible methods for the string object. The compiler knows it is a string. And it knows the methods from the String prototype. But it also provides the method signature. This is very interesting because we don't necessarily need to go to the docs. The "docs" is already in our code editor.

It's an awesome experience while coding.

The type definition "on hover" is another thing that we saw earlier in this article. Let the compiler infer the types implicitly and you won't lose the type documentation. Using the hover in the object, the IDE or editor will always be able to show the type definition.

Another interesting thing is that TypeScript will not only flag what could go wrong on runtime, but it also helps to find code that doesn't do what you intend.

Imagine we have a function to open a snackbar if it is still closed. It would verify the status of the snackbar. If it is closed, just call another function to open it.

const buildSnackbar = (status: SnackbarStatus) => {
  if (status.isClosed) {
    openSnackbar();
  }
};

And the type information for this snackbar is:

type SnackbarStatus = {
  isClosed: boolean;
};

What happens if I call this function like this:

buildSnackbar({ isclosed: true });

It won't break in runtime, because the status object has no isClosed attribute and the undefined object is a falsy value, so it will skip the if condition and not call the openSnackbar function. No runtime error. But probably it will behavior different than the expected.

In TypeScript, the compiler will give some hints to make it works properly. First it will show this error:

// Argument of type '{ isclosed: boolean; }' is not assignable to
// parameter of type 'SnackbarStatus'.

isclosed with downcased C is not assignable to the type. It's not defined there. This is the first hint to make you correct your code.

The second is even better:

// Object literal may only specify known properties,
// but 'isclosed' does not exist in type 'SnackbarStatus'.
// Did you mean to write 'isClosed'?

It tells exactly what you probably need to do: rename the isclosed to isClosed.

We can talk a lot of things about the tooling about I think this is the main part.

My suggestion to learn more about this is to just code in TypeScript and "have a conversation" with the compiler. Read the errors. Play with the hover. See the autocompletion. Understand the method signatures. It's really a productive way to code.

Tips & Learnings

As the article is coming to an end, I want to just add some final thoughts, learnings, and tips to help you in your journey learning TypeScript or just applying it in your projects.

• Really read the type error: this will help you better understand the issue and the types.
• strictNullChecks and noImplicitAny can be very helpful in finding bugs. Enable this as soon as possible in your project. Use strictNullChecks to prevent “undefined is not an object”-style runtime errors. Use noImplicitAny to type the source code to give more type information for the compiler.
• Together with the compiler's configurations, I always recommend being very precise about your types. Mainly with the values that occur only in runtime like an API response. Correctness is important to catch as many bugs as possible in compile time.
• Understand the difference between runtime and compile time: types only affect in compile type. It runs the type checker and then compiles to JavaScript. The JavaScript source code doesn't use any type of references or type operations.
• Learn about utility types. We talked more specifically about the Readonly in the immutability in compile time, but TypeScript has a box of helpers like Required, Pick, and many more.
• If possible, prefer letting the compiler infers the types for you. Most of the types and returning types are redundant. The TypeScript compiler is very smart in this area. If not possible, you can always add type annotations. And leave the type assertions as the last option.
• As you're writing code, take a look at the tooling. The design of the tooling provided in an IDE is amazing. The IntelliSense and type checking provide a really good experience.

This post was originally published at TK's blog. And you can find more content like this in my blog at https://leandrotk.github.io/tk.

You can also follow me on Twitter and GitHub.

Resources

I compiled (pun very much intended!) a bunch of resources to help you learn more about programming languages, type systems, and the type mental model.

Also, if you found the examples on this post useful, I added all of them this repository: Thinking in Types. So you can fork and play with it.

Type Systems

• Type Compatibility
• Type Systems: Structural vs. Nominal typing explained
• Learning TypeScript: Structural vs nominal typing systems
• Constraints Liberate, Liberties Constrain — Runar Bjarnason
• Type Narrowing in TypeScript
• TypeScript: narrowing types via type guards and assertion functions
• TypeScript Learnings: Interesting Types

Tooling & Developer Experience

• Advanced TypeScript tooling at scale
• Type Systems & Props Design
• Anders Hejlsberg on Modern Compiler Construction
• TypeScript Compiler explained by the Author Anders Hejlsberg

Compile time vs Runtime

• Compile time vs Runtime
• Compile error vs Runtime error
• Value space and Type space
• A playground tool to play with TypeScript and see the JavaScript output

Best Practices

• TypeScript Best Practices
• Do's and Don'ts for General Types

Books

• Programming with Types Book
• Effective TypeScript: 62 Specific Ways to Improve Your TypeScript Book
• Thinking with Types

In order to get started with C++, you will need to learn a little about compilers and how C++ runs on your computer.

When all is said and done, computers only understand one language, machine language. Machine language is entirely made up of binary bits, or 0s and 1s.

While it would be possible to program in binary, it would be incredibly tedious and time consuming. So, we humans developed programming languages to make it easier to develop software.

Assembly language is a direct 1 to 1 with machine language. Languages like C, C++, and COBOL are a little higher and need to be compiled down. It goes even higher. Languages like JavaScript and Python have components that get translated into C++ or other low level languages before they get compiled, effectively making them “higher” languages than C or C++.

Because computer architecture is made up of electronic switches and cables that can only work with binary 1s and 0s, you need a compiler to translate your code from high level C++ to machine language that the CPU can understand.

How compilers work

Compilers are utility programs that take your code and transform it into executable machine code files.

When you run a compiler on your code, first, the preprocessor reads the source code (the C++ file you just wrote). The preprocessor searches for any preprocessor directives (lines of code starting with a #). Preprocessor directives cause the preprocessor to change your code in some way (by usually adding some library or another C++ file).

Next, the compiler works through the preprocessed code line by line translating each line into the appropriate machine language instruction. This will also uncover any syntax errors that are present in your source code and will throw an error to the command line.

Finally, if no errors are present, the compiler creates an object file with the machine language binary necessary to run on your machine. While the object file that the compiler just created is likely enough to do something on your computer, it still isn’t a working executable of your C++ program. There is a final important step to reach an executable program.

C++ contains a vast library to aid in performing difficult tasks like I/O and hardware manipulation. You can include these libraries with preprocessor directives, but the preprocessor doesn’t automatically add them to your code.

In order for you to have a final executable program, another utility known as the linker must combine your object files with the library functions necessary to run the code.

Think of it as having all the necessary blocks to build a house. The compiler made all the blocks but the linker is the one that sticks them all together to finally create a house. Once this is done, you now have a functioning executable file!

How to Compile a file

Let’s say you have a C++ file called helloWorld.cpp …

If you are on Windows

Using and IDE like CodeBlocks

It is as simple as clicking the build and run buttons, they will create a file in the project folder.

Using Command Prompt

1. Open a Developer Command Prompt - For this step, you will need to have Microsoft Visual Studio or some other IDE that enables you to compile your program from the command line. You can also search online for C++ compilers.
2. Navigate to the source code directly
3. Run the Compiler on your source code (assuming you are using the Microsoft Visual Studio compiler) cl /EHsc helloWorld.cpp

This will now create an object file and automatically link it for you. If you look in that same folder, you will see a hellWorld.exe executable file (note the exe extension) is now present.

1. Type helloWorld into the prompt to run the executable

Alternatively, many IDEs allow for quick building and viewing of your program. This may be easier since your version of windows may not come pre packaged with a compiler utility.

If you are on Linux or OSX

1. Open up a terminal window and navigate to the source code directory
2. Run the Compiler on your source code g++ helloWorld.cpp -o helloWorld

This will create an object file and automatically link it for you. Look in the folder and you will see a helloWorld.exe executable file (note the exe extension).

1. Type ./helloWorld in the terminal window to run the executable file

g++ is the standard Linux compiler and is a great utility. It comes packaged with the operating system.

NOTE: to compile and execute your code directly, run g++ -o helloWorld helloWorld.cpp; ./helloWorld so when you need to compile and run your code multiple times, up arrow-enter.

There are a number of different types of compilers. The two listed are the two that are usually packaged with Windows or Linux/OSX.

More info on C++

• Intro to C++ programming
• Object-oriented programming in C++
• Graph algorithms and data structures explained in C++ and Java
• How to compile your C++ code in VS Code

Dynamic compilation has some advantages over static compilation. When running Java or C# applications, the runtime environment can profile the application while it is being run. This allows for more optimized code to be generated. If the behavior of the application changes while it is running, the runtime environment can recompile the code.

Some of the disadvantages include startup delays and the overhead of compilation during runtime. To limit the overhead, many JIT compilers only compile the code paths that are frequently used.

Overview

Traditionally there are two methods for converting source code into a form that can be run on a platform. Static compilation converts the code into a language for a specific platform. An interpreter directly executes the source code.

JIT compilation attempts to use the benefits of both. While the interpreted program is being run, the JIT compiler determines the most frequently used code and compiles it to machine code. Depending on the compiler, this can be done on a method or smaller section of code.

Dynamic compilation was first described in a paper by J. McCarthy on LISP in 1960.

Just In Time Compilation, JIT, or Dynamic Translation, is compilation that is being done during the execution of a program. Meaning, at run time, as opposed to prior to execution. What happens is the translation to machine code. The advantages of a JIT are due to the fact, that since the compilation takes place in run time, a JIT compiler has access to dynamic runtime information enabling it to make better optimizations (such as inlining functions).

What is important to understand about the JIT compilation, is that it will compile the bytecode into machine code instructions of the running machine. Meaning, that the resulting machine code is optimized for the running machine’s CPU architecture.

Some examples of JIT Compilers are JVM (Java Virtual Machine) in Java and CLR (Common Language Runtime), in C#.

History

In the beginning, a compiler was responsible for turning a high-level language (defined as higher level than assembler) into object code (machine instructions), which would then be linked (by a linker) into an executable.

At one point in the evolution of languages, compilers would compile a high-level language into pseudo-code, which would then be interpreted (by an interpreter) to run your program. This eliminated the object code and executables, and allowed these languages to be portable to multiple operating systems and hardware platforms. Pascal (which compiled to P-Code) was one of the first; Java and C# are more recent examples. Eventually the term P-Code was replaced with bytecode, since most of the pseudo-operations are a byte long.

A Just-In-Time (JIT) compiler is a feature of the run-time interpreter, that instead of interpreting bytecode every time a method is invoked, will compile the bytecode into the machine code instructions of the running machine, and then invoke this object code instead. Ideally the efficiency of running object code will overcome the inefficiency of recompiling the program every time it runs.

Typical scenario

The source code is completely converted into machine code

JIT scenario

The source code will be converted into assembly language like structure [for ex IL (intermediate language) for C#, ByteCode for java].

The intermediate code is converted into machine language only when the application needs that is required codes are only converted to machine code.

JIT vs Non-JIT comparison

In JIT not all the code is converted into machine code first a part of the code that is necessary will be converted into machine code then if a method or functionality called is not in machine then that will be turned into machine code, which reduces burden on the CPU. As the machine code will be generated on run time, the JIT compiler will produce machine code that is optimized for running machine’s CPU architecture.

Some examples of JIT are:

• Java: JVM (Java Virtual Machine)
• C#: CLR (Common Language Runtime)
• Android: DVM (Dalvik Virtual Machine) or ART (Android RunTime) in newer versions

The Java Virtual Machine (JVM) executes bytecode and maintains a count as of how many time a function is executed. If this count exceeds a predefined limit JIT compiles the code into machine language which can directly be executed by the processor (unlike the normal case in which javac compiles the code into bytecode and then Java, the interpreter interprets this bytecode line by line converts it into machine code and executes).

Also next time this function is calculated same compiled code is executed again unlike normal interpretation in which the code is interpreted again line by line. This makes execution faster.

Have you ever noticed that, when you are writing code in a text editor like VS code, it recognizes things like unmatched braces? And it also sometimes warns you, with an irritating red highlight, about the incorrect syntax that you have written?

If not, then think about it. That is after all a piece of code. How can you write code for such a task? What would be the underlying logic behind it?

These are the kinds of questions that you will face if you have to write a compiler for a programming language. Writing a compiler is not an easy task. It is bulky job that demands a significant amount of time and effort.

In this article, we are not going to talk about how to build compilers. But we will talk about a concept that is a core component of the compiler: Context Free Grammars.

Introduction

All the questions we asked earlier represent a problem that is significant to compiler design called Syntax Analysis. As the name suggests, the challenge is to analyze the syntax and see if it is correct or not. This is where we use Context Free Grammars. A Context Free Grammar is a set of rules that define a language.

Here, I would like to draw a distinction between Context Free Grammars and grammars for natural languages like English.

Context Free Grammars or CFGs define a formal language. Formal languages work strictly under the defined rules and their sentences are not influenced by the context. And that's where it gets the name context free.

Languages such as English fall under the category of Informal Languages since they are affected by context. They have many other features which a CFG cannot describe.

Even though CFGs cannot describe the context in the natural languages, they can still define the syntax and structure of sentences in these languages. In fact, that is the reason why the CFGs were introduced in the first place.

In this article we will attempt to generate English sentences using CFGs. We will learn how to describe the sentence structure and write rules for it. To do this, we will use a JavaScript library called Tracery which will generate sentences on the basis of rules we defined for our grammar.

Before we dive into the code and start writing the rules for the grammar, let's just discuss some basic terms that we will use in our CFG.

Terminals: These are the characters that make up the actual content of the final sentence. These can include words or letters depending on which of these is used as the basic building block of a sentence.

In our case we will use words as the basic building blocks of our sentences. So our terminals will include words such as "to", "from", "the", "car", "spaceship", "kittens" and so on.

Non Terminals: These are also called variables. These act as a sub language within the language defined by the grammar. Non terminals are placeholders for the terminals. We can use non terminals to generate different patterns of terminal symbols.

In our case we will use these Non terminals to generate noun phrases, verb phrases, different nouns, adjectives, verbs and so on.

Start Symbol: a start symbol is a special non terminal that represents the initial string that will be generated by the grammar.

Now that we know the terminology let's start learning about the grammatical rules.

While writing grammar rules, we will start by defining the set of terminals and a start state. As we learned before, that start symbol is a non-terminal. This means it will belong to the set of non-terminals.

T: ("Monkey", "banana", "ate", "the")
S: Start state.

And the rules are:

S --> nounPhrase verbPhrase
nounPhrase --> adj nounPhrase | adj noun
verbPhrase --> verb nounPhrase
adjective  --> the
noun --> Monkey | banana
verb --> ate

The above grammatical rules may seem somewhat cryptic at first. But if we look carefully, we can see a pattern that is being generated out of these rules.

A better way to think about the above rules is to visualise them in the form of a tree structure. In that tree we can put S in the root and nounPhrase and verbPhrase can be added as children of the root. We can proceed in the same way with nounPhrase and verbPhrase too. The tree will have terminals as its leaf nodes because that is where we end these derivations.

In the above image we can see that S (a nonterminal) derives two non terminals NP(nounPhrase) and VP(verbPhrase). In the case of NP, it has derived two non terminals, Adj and Noun.

If you look at the grammar, NP could also have chosen Adj and nounPhrase. While generating text, these choices are made randomly.

And finally the leaf nodes have terminals which are written in the bold text. So if you move from left to right, you can see that a sentence is formed.

The term often used for this tree is a Parse Tree. We can create another parse tree for a different sentence generated by this grammar in a similar way.

Now let's proceed further to the code. As I mentioned earlier, we will use a JavaScript library called Tracery for text generation using CFGs. We will also write some code in HTML and CSS for the front-end part.

The Code

Let's start by first getting the tracery library. You can clone the library from GitHub here. I have also left the link to the GitHub repository by galaxykate at the end of the article.

Before we use the library we will have to import it. We can do this simply in an HTML file like this.

<html>
    <head>
        <script src="tracery-master/js/vendor/jquery-1.11.2.min.js"></script>
        <script src="tracery-master/tracery.js"></script>
        <script src="tracery-master/js/grammars.js"></script>
        <script src='app.js'></script>
    </head>

</html>

I have added the cloned tracery file as a script in my HTML code. We will also have to add JQuery to our code because tracery depends on JQuery. Finally, I have added app.js which is the file where I will add rules for the grammar.

Once that is done, create a JavaScript file where we will define our grammar rules.

var rules = {
        "start": ["#NP# #VP#."],
        "NP": ["#Det# #N#", "#Det# #N# that #VP#", "#Det# #Adj# #N#"],
        "VP": ["#Vtrans# #NP#", "#Vintr#"],
        "Det": ["The", "This", "That"],
        "N": ["John Keating", "Bob Harris", "Bruce Wayne", "John Constantine", "Tony Stark", "John Wick", "Sherlock Holmes", "King Leonidas"],
        "Adj": ["cool", "lazy", "amazed", "sweet"],
        "Vtrans": ["computes", "examines", "helps", "prefers", "sends", "plays with", "messes up with"],
        "Vintr": ["coughs", "daydreams", "whines", "slobbers", "appears", "disappears", "exists", "cries", "laughs"]
    }

Here you will notice that the syntax for defining rules is not much different from how we defined our grammar earlier. There are very minor differences such as the way non-terminals are defined between the hash symbols. And also the way in which different derivations are written. Instead of using the "|" symbol for separating them, here we will put all the different derivations as different elements of an array. Other than that, we will use the semicolons instead of arrows to represent the transition.

This new grammar is a little more complicated than the one we defined earlier. This one includes many other things such as Determiners, Transitive Verbs and Intransitive Verbs. We do this to make the generated text look more natural.

Let's now call the tracery function "createGrammar" to create the grammar we just defined.

let grammar = tracery.createGrammar(rules);

This function will take the rules object and generate a grammar on the basis of these rules. After creating the grammar, we now want to generate some end result from it. To do that we will use a function called "flatten".

let expansion = grammar.flatten('#start#');

It will generate a random sentence based on the rules that we defined earlier. But let's not stop there. Let's also build a user interface for it. There's not much we will have to do for that part – we just need a button and some basic styles for the interface.

In the same HTML file where we added the libraries we will add some elements.

<html>
    <head>
        <title>Weird Sentences</title>
        <link rel="stylesheet" href="style.css"/>
        <link href="https://fonts.googleapis.com/css?family=UnifrakturMaguntia&display=swap" rel="stylesheet">
        <link href="https://fonts.googleapis.com/css?family=Harmattan&display=swap" rel="stylesheet">

        <script src="tracery-master/js/vendor/jquery-1.11.2.min.js"></script>
        <script src="tracery-master/tracery.js"></script>
        <script src="tracery-master/js/grammars.js"></script>
        <script src='app.js'></script>
    </head>
    <body>
        <h1 id="h1">Weird Sentences</h1>
        <button id="generate" onclick="generate()">Give me a Sentence!</button>
        <div id="sentences">

        </div>
    </body>
</html>

And finally we will add some styles to it.

body {
    text-align: center;
    margin: 0;
    font-family: 'Harmattan', sans-serif;
}

#h1 {
    font-family: 'UnifrakturMaguntia', cursive;
    font-size: 4em;
    background-color: rgb(37, 146, 235);
    color: white;
    padding: .5em;
    box-shadow: 1px 1px 1px 1px rgb(206, 204, 204);
}

#generate {
    font-family: 'Harmattan', sans-serif;
    font-size: 2em;
    font-weight: bold;
    padding: .5em;
    margin: .5em;
    box-shadow: 1px 1px 1px 1px rgb(206, 204, 204);
    background-color: rgb(255, 0, 64);
    color: white;
    border: none;
    border-radius: 2px;
    outline: none;
}

#sentences p {
    box-shadow: 1px 1px 1px 1px rgb(206, 204, 204);
    margin: 2em;
    margin-left: 15em;
    margin-right: 15em;
    padding: 2em;
    border-radius: 2px;
    font-size: 1.5em;
}

We will also have to add some more JavaScript to manipulate the interface.

let sentences = []
function generate() {
    var data = {
        "start": ["#NP# #VP#."],
        "NP": ["#Det# #N#", "#Det# #N# that #VP#", "#Det# #Adj# #N#"],
        "VP": ["#Vtrans# #NP#", "#Vintr#"],
        "Det": ["The", "This", "That"],
        "N": ["John Keating", "Bob Harris", "Bruce Wayne", "John Constantine", "Tony Stark", "John Wick", "Sherlock Holmes", "King Leonidas"],
        "Adj": ["cool", "lazy", "amazed", "sweet"],
        "Vtrans": ["computes", "examines", "helps", "prefers", "sends", "plays with", "messes up with"],
        "Vintr": ["coughs", "daydreams", "whines", "slobbers", "appears", "disappears", "exists", "cries", "laughs"]
    }

    let grammar = tracery.createGrammar(data);
    let expansion = grammar.flatten('#start#');

    sentences.push(expansion);

    printSentences(sentences);
}

function printSentences(sentences) {
    let textBox = document.getElementById("sentences");
    textBox.innerHTML = "";
    for(let i=sentences.length-1; i>=0; i--) {
        textBox.innerHTML += "<p>"+sentences[i]+"</p>"
    }
}

Once you have finished writing the code, run your HTML file. It should look something like this.

Every time you click the red button it will generate a sentence. Some of these sentences might not make any sense. This is because, as I said earlier, CFGs cannot describe the context and some other features that natural languages possess. It is used only to define the syntax and structure of the sentences.

You can check out the live version of this here.

Conclusion

If you have made it this far, I highly appreciate your resilience. It might be a new concept for some of you, and others might have learnt about it in their college courses. But still, Context Free Grammars have interesting applications that range widely from Computer Science to Linguistics.

I have tried my best to present the main ideas of CFGs here, but there is a lot more that you can learn about them. Here I have left links to some great resources:

• Context Free Grammars by Daniel Shiffman.
• Context Free Grammars Examples by Fullstack Academy
• Tracery by Galaxykate

In simple terms, C++ is a sophisticated, efficient, general-purpose programming language based on C.

It was developed by Bjarne Stroustrup in 1979.

One of C++'s main features is the compiler. This is used to compile and run C++ code.

A compiler is a special program that processes statements written in a particular programming language like C++ and turns them into machine language or "code" that a computer's processor uses. (Source)

I actually wrote this article because I had a C++ assignment which required using a compiler. As usual, everyone was using the CodeBlocks IDE and Visual Studio IDE. But I was already used to Visual Studio Code for all my programming stuff.

I then set out to find a way of compiling C++ directly inside my own VsCode Editor, hence this article :).

In this article, I'll show you how to set up your compiler in VsCode and give you some links to some of the best C++ resources.

Prerequisites

• Prior knowledge of C++
  (I assume you're learning C++, about to start learning, or just reading this for fun. This article is not a C++ 101 tutorial – some understanding of C++ is needed.)

• Visual Studio Code Editor
  Download here and read the setup docs for Windows, Linux and Mac

• Internet connection (!important)

Disclaimer!

I will be using a Windows OS throughout this article, but I'll provide links to resources that will help those using other operating systems.

Now let's get started!

Download and install a C++ compiler

• Head to www.mingw.org and click the “Download/Installer” link to download the MinGW setup file, or click here for Windows, here for Linux, and here for Mac

MinGW, a contraction of "Minimalist GNU for Windows", is a minimalist development environment for native Microsoft Windows applications. (Source)

• After downloading, install MinGW and wait for the “MinGW Installation Manager” to show up.

• When the “MinGW Installation Manager” shows up, click on mingw32-gcc-g++ then select “Mark for Installation”

• In the menu at the top left corner, click on “Installation > Apply Changes”

• Wait and allow to install completely. Ensure you have a stable internet connection during this process.

Edit your PATH environment variable to include the directory where the C++ compiler is located

PATH is an environment variable on Unix-like operating systems, DOS, OS/2, and Microsoft Windows, specifying a set of directories where executable programs are located. In general, each executing process or user session has its own PATH setting. - Wikipedia

After installing MinGW, it can be found in C:\MinGW\bin. Now you have to include this directory in your environment variable PATH. If you've been using computers for a while now you should know how to do this already, but if you don't, here are a few resources:

• Click here for a Windows OS guide

• Click here for Linux

• Click here for a Mac OS guide

Install Code Runner extension in VS Code

Now we have our compiler set up, let's install Code Runner

Code Runner allows you to Run code snippet or code file for multiple languages:

C, C++, Java, JavaScript, PHP, Python, Perl, Perl 6, Ruby, Go, Lua, Groovy, PowerShell, BAT/CMD, BASH/SH, F# Script, F# (.NET Core), C# Script, C# (.NET Core), VBScript, TypeScript, CoffeeScript, Scala, Swift, Julia, Crystal, OCaml Script, R, AppleScript, Elixir, Visual Basic .NET, Clojure, Haxe, Objective-C, Rust, Racket, AutoHotkey, AutoIt, Kotlin, Dart, Free Pascal, Haskell, Nim, D, Lisp, Kit, and custom command.

• Click here to download

• Or search in VsCode marketplace tab

• After installing restart VsCode

• Open your C++ file in Vscode. Here's a basic hello world program below:

#include <iostream>
using namespace std;
int main() 
{
    cout << "Hello world!";
    return 0;
}

Save this file as test.cpp

Run your code using Code Runner

• Use the shortcut Ctrl+Alt+N

• Or press F1 and then select/type Run Code

• Or right-click the Text Editor and then click Run Code in the editor context menu

The code will run and the output will be shown in the Output Window. Open the output window with `Ctrl+ shortcut.

To stop the running code

• Use the shortcut Ctrl+Alt+M

• Or press F1 and then select/type Stop Code Run

• Or right-click the Output Channel and then click Stop Code Run in the context menu

Hurray, you just successfully set up your C++ environment in VsCode!

Conclusion

Here's a quick hint: By default, VsCode's output terminal is read-only. If you're running code that requires user input like:

#include <iostream>
using namespace std;

const double pi = 3.14159; 

void calculate()
{
  double area; 
  double radius;

  cout<<"Enter Radius: "<<endl; 
  cin>>radius;

  area = pi * radius * radius; 

  cout<<"area is: "<<area<<endl;
 }

int main()
{
  calculate(); 
  return 0;
}

you won't be able to type into the terminal, Cannot edit in read-only terminal.
To fix this, you need to manually enable read-write.

• In VsCode, Go to File > Preference > Setting.

• In the User tab on the left panel, find the extensions section

• Scroll and find 'Run Code Configuration'

• Scroll and find a checkbox Run in Terminal (Whether to run code in Integrated Terminal) Check the box.

OR

• In your setting.json file, add:

"code-runner.runInTerminal": true

Hurray, you're done and ready to roll :).

C++ resources

Here are some C++ resources you can use to get started with learning C++

• https://www.learncpp.com/

• https://www.codecademy.com/learn/learn-c-plus-plus

• https://www.udemy.com/free-learn-c-tutorial-beginners/

• https://www.sololearn.com/Course/CPlusPlus/

• https://www.youtube.com/watch?v=vLnPwxZdW4Y

• https://www.tutorialspoint.com/cplusplus/cpp_useful_resources.htm

• https://makeawebsitehub.com/learning-c/

Credits

• MinGW Project

• Code Runner by Jun Han

Thank you for reading!

Compilers are awesome! ? ? ? They combine theory and application and touch on a lot of software related topics such as parsing and language construction. At their core, compilers are a program that make a program readable by the computer.

The inspiration for this came out of a compilers course I took this past Fall and my love for Go.

This is the guide I wish I had when starting my journey into compilers. There are a lot of books, videos, and tutorials on how to create compilers. The goal of this post is to strike a balance between providing a nontrivial example of some of the things a compiler can do while avoid getting stuck in the weeds. ?

The result will be a compiler that can execute a small made up language.To checkout and run the final project see the instructions below. ?

Note: Remember that Go is strict about absolute paths when running this

cd $GOPATH/src/github.com/Lebonescogit clone https://github.com/Lebonesco/go-compiler.gitcd go-compilergo test -vgo run main.go ./examples/math.bx

Outline of the Compiler

• Lexer/Parser
• AST Generator
• Type Checker
• Code Generation

The Language

The goal of this post is to get you familiar with compilers as quickly as a possible so we’ll keep the language simple. For Types we’ll work with strings, integers, and bools. It will have Statements that include func, if, else, let, and return. This should be enough to have fun working with some of the complexities of a compiler.

The first compiler that I built, I completed over the course of two months and took up 1000’s of lines of code. I took some shortcuts in this post in order to show you the key fundamentals.

Two common components that our language is missing are classes and arrays. These add additional complications we don’t have time for right now. If it turns out that people really want to know how to handle these elements I’ll write a followup.

Some example code:

func add(a Int, b int) Int {    return a + b;}

func hello(name String) String {    return "hello:" + " " + name;}

let num = add(1, 2);let phrase = string hello("Jeff");let i = int 0;let result = "";

if (i == 2) {    result = hello("cat");} else {    result = hello("dog");}

PRINT(result);

Quick Setup

The only outside package we need is **gocc**, which will help build the lexer and parser.

To get it run:

go get github.com/goccmack/gocc

Make sure the bin folder where gocc is located is in your **PATH** :

export PATH=$GOPATH/bin:$PATH

Note: If you’re having problems at this stage try running go env to make sure that your $GOROOT and $GOPATH are correctly assigned.

Cool, let’s dive into some code.

Building the Lexer

The lexer’s job is to read the program and output a stream of tokens that are consumed by the parser. Each Token contains the type that the token represents in the language and the string Literal of that token.

To identify the pieces of the program we will be using regular expressions. gocc will then convert these regular expressions into a DFA (Deterministic Finite Automata) which can theoretically run in linear time.

The notation that we’ll be using is BNF (Backus–Naur form). Don’t confuse this with EBNF (extended Backus–Naur form) or ABNF (augmented Backus–Naur form) which have some added features. Keep this in mind when looking at other examples online that could be using other forms which provide more syntactic sugar.

Let’s start with the basics and define what strings and integers will look like.

Note that:

• All token names must be lower case
• Any key preceded by ‘!’ will be ignored
• Any key preceded by ‘_’ will not by turned into a token
• Any expression enclosed by ‘{‘ expression ‘}’ can be repeated 0 or more times

In the below example we are ignoring all white space and have defined an int and string_literal token.

Every language has built in keywords that are reserved words that deliver special functionality. But, how will the lexer know whether a string is a keyword or a user created identifier? It handles this be giving preference to the order in which tokens are defined. Therefore, let’s define keywords next.

We’ll finish this up by adding the punctuation necessary for expressions.

Cool! Let’s see if this is actually doing what we want with some unit tests. Feel free to just paste this part into your IDE. ?

Note: It’s generally good practice in Go to place test files in the relevant subdirectory, but for simplicity I’m placing all tests in the root.

To test our scanner run:

$ gocc grammer.bnf$ go test -v=== RUN   TestToken--- PASS: TestToken (0.00s)PASSok      github.com/Lebonesco/compiler       0.364s

Great, we now have a working **Lexer** ?

Building the Parser

Building the **Parser** is similar to how we built the **Lexer**. We will construct a set of element sequences that when correctly match a stream of tokens produce a grammar. This will also run in linear time by internally converting our NFA (Non-Deterministic Automaton) grammar to DFA (Deterministic Finite Automaton).

Let’s keep things simple. What actually is our program? Well, it’s a bunch of Statements in which each Statement can contain a set of Statements and/or Expressions. This seems like a good place to start our grammar.

Below is the beginning recursive hierarchy of the program. Statements is a sequence of zero or more Statements and Functions is a list of functions. Our languages requires functions to be defined before other Statement types. This will reduce some headache during the type checking phase. empty is a keyword in BNF that represents an empty space.

But wait! What is a Statement? It’s a unit of code that doesn’t return a value. This includes: if, let, and return statements. This is opposed to Expressions which do return values. We will get to those next.

Below is our grammar for Statement and Function. A StatementBlock is a larger abstraction that encapsulates a list of Statements with braces { }.

Next lets build out our Expression which handles all infix operations such as +, -, *, &lt;, &gt;, ==, and, and or.

Almost done with a fully working grammar! Let’s wrap things up by defining our parameter insertion. Each function can accept any amount of values. When defining a function we need to label the argument types in the signature while a called function can accept any amount of Expressions.

Now that our parser is completed let’s add some code to our driver, main.go.

As we progress through the compiler we will add more functionality to this driver.

One of the things challenging about building a parser is that there’re many different ways to define the grammar. ?

We won’t really know how well we did until we get into the next section which uses the output we just generated. The difficulty of building the static type checker will be strongly influenced by our grammar design. Keep your fingers crossed ?.

Test Parser

We’ll keep this simple because at this point our parser can still produce false positives. Once we start working on the AST we can check its accuracy.

go test -v=== RUN   TestParser--- PASS: TestParser (0.00s)=== RUN   TestToken--- PASS: TestToken (0.00s)PASSok      github.com/Lebonesco/go-compiler        7.295s

Congrats ? ? ?! You now have a fully working Lexer and Parser. Time to move onto the AST (Abstract Syntax Tree).

Abstract Syntax Tree

The best way to understand an abstract syntax tree is in relation to a parse tree which is what we generated in the last post. A parse tree represents each part of the program that is matched in our grammar.

By contrast, an AST only contains the information related to type checking and code generation, and skips any other extra content that is used while parsing the text.

Don’t worry if that definition doesn’t makes sense right now. I always learn best by actually coding, so let’s jump into it!

Create a new directory and two new files. ast.go will contain our AST generating functions and types.go will have the tree node types.

mkdir astcd asttouch ast.gotouch types.go

Like with the parse tree, we will define our structure from top to bottom. Every node will either be a Statement or Expression. Go isn’t object oriented so we’ll use a composition pattern utilizing interface and struct to represent our node categories. Our AST will return a Program node that contains the rest of the program. From now on, any struct we created with a TokenLiteral() method is a node. If that node has a statementNode() method it will fit the Statement interface and if it has a expressionNode() method it’s an Expression.

In addition, we’ll be adding json tags to each struct field to make it easier when we convert our AST into json for testing purposes.

Now let’s start building our Statement structs based off of the Statement and Node interfaces.

Note: json:"-" means that the field will be omitted from our json.

Next we need some hooks to connect our nodes and parser. The code below allows our Statement nodes to fit the Node and Statement interfaces.

We then need the hooks that will be called by the parser.

As you can see, most of our code is checking and casting our input type.

These hooks will then be called by the parser in grammar.bnf. To access these functions we’ll need to import "github.com/Lebonesco/go-compiler/ast.

Now when a piece of grammar is identified, it calls an AST hook and passes in the necessary data to construct a node.

As you could imagine, there is a lot of flexibility in how you want to generate your AST. There are design strategies that reduce the amount of unique nodes in the AST . However, having more node types will make your life easier when we get to the typechecker and code generation. ?

This part has a lot of code. However, it’s not very difficult and mostly all the same. The error handling in Go can feel a bit tedious, but in the long run it’ll be worth it when we make a silly mistake. Safety First ?

We’re not going to do anything too crazy with our error handling because I want to save on lines of code. However, if you feel so inclined you can add more descriptive and useful errors.

Let’s move on to Expressions!

Fit them into the Node and Expression interfaces.

And create the Expression hooks.

Finally, insert the hooks into the parser.

Test AST Generator

The test cases for the AST generator are the most tedious to write. But trust me, this is not a part you want to mess up on. If you have problems here, those bugs will rollover into your type checker and code generator. ?

In my opinion, if code doesn’t have tests it’s broken

In our AST test we will construct what our final result should look like. To avoid comparing elements such as tokens, that could create false negatives, we convert our result and expected output into json before comparing with a deep comparison function, reflect.DeepEqual().

Run Test:

go test -v=== RUN   TestAST--- PASS: TestAST (0.00s)=== RUN   TestParser--- PASS: TestParser (0.00s)=== RUN   TestToken--- PASS: TestToken (0.00s)PASSok      github.com/Lebonesco/go-compiler        9.020s

Half way to a working compiler! ? While you give this post some ? ? ? don’t forget to give yourself a hand for making it this far.

Let’s add some more code to the driver.

Now onto my favorite part, the Type Checker.

Type Checker

Our type checker will make sure that users don’t write code that conflicts with our statically typed language.

The core backbone of our type checker will be a combination of data structures that track identifier types, initialization, and valid type operations. This can get vastly more complicated once we start dealing with different levels of scope and classes. However, we’re keeping it as simple as possible. ?

To start:

touch checker_test.gomkdir checkercd checkertouch checker.gotouch environment.go

environment.go will contain all of our helper functions that will be used by our checker and code generator to access and manipulate our set of variables and corresponding types. Our environment is simple so this will be straight forward.

We’ll begin by setting all of our constant values including operation types, variable types, and mapping of each type to its valid methods.

Note: If we had classes in our language our checker would handle this third part rather than us doing it by hand.

The rest of environment.go are basic getters and setters that handle identifiers and functions.

The foundation of our type checker will be a single dispatch function, checker(), that takes in a Node and fires the corresponding checker function

I felt like saving lines of code so we’ll be using a global environment to store our variable types.

Note: This wouldn’t be possible if we allowed Block Statements and Functions to have their own scope or if we were abiding by best practices.

Now eval Statements. Block Statements are the only statement in which we return a type in order to handle the case when it is inside a function. If there is a Return Statement inside the Block Statement its type is returned. Otherwise, the Nothing_Type is returned.

Onto evaluating Expressions. The most complicated part will be evalFunctionCall() because it could either be a built in function such as PRINT() or user defined.

Note: Currently, there is only one builtin function. However, more could be easily added given the framework that we’ve built.

Awesome! Let’s add a small snippet to our driver.

Test Type Checker

go test -v=== RUN   TestAST--- PASS: TestAST (0.00s)=== RUN   TestOperations--- PASS: TestOperations (0.00s)=== RUN   TestIdents--- PASS: TestIdents (0.00s)=== RUN   TestFunctions--- PASS: TestFunctions (0.00s)=== RUN   TestParser--- PASS: TestParser (0.00s)=== RUN   TestToken--- PASS: TestToken (0.00s)PASSok      github.com/Lebonesco/go-compiler        9.020s

I made some deliberate choices to leave things out of this language such as classes, for loops, and function scope. Most of the complexities that arise from these occur in the checker and code generator. If I added those elements this post would be a lot lot longer. ?

Code Generation

We have finally made it to the last stage! ? ? ?

In order to handle the most cases with the least amount of hassle every expression will be assigned to a temporary variable. It might make our generated code look bloated, but it will solve for any nested expressions.

Bloated code won’t have any impact on final program speed because the optimizer will remove any redundancy when we compile our final generated C++ code.

Our generator will look similar to the type checker. The main difference is that we’ll be passing down a buffer to store the generated code.

While I chose to compile into C++, you can substitute in any language . The main purpose of this Go Compiler Guide was to enable you to be able to understand the pieces well enough to go out and create your own.

To start:

touch gen_test.gomkdir gencd gentouch gen.go

We’ll begin by importing all of the necessary packages and defining three utility functions, write() to write generated code to a buffer, check()to do error handling, and freshTemp()to generate unique variable names for temporary variables we create on the fly.

Note: It’s generally bad practice to use panic()for normal error handling in Go, but I’m tired of writing if statements.

Similar to the checker, our generator has a core dispatch function that accepts a Node and calls the corresponding gen function.

Let’s generate some Statements. genProgram() generates necessary headers and main() function.

Generating Expressions will look very similar to the code above. The main difference is that a temp variable is returned representing that expression. This helps us handle more complex Expression nesting.

The final piece of code will be our C++ Builtin types. Without this nothing will work.

Test Code Generator

Bringing It All Together

We’re now going to combine our lexer, parser, AST generator, type checker, and code generator into a final runnable program, main.go.

Note: I’m running this on a Windows so my C++ compiles into main.exe. If this doesn’t work for you remove the .exe extension.

To find some test programs to run go to github.com/Lebonesco/go-compiler/examples.

go run main.go ./example/function.bxhello Jeff3

And there you have it! We have completed a fully working compiler in Go!

Thank you for taking the time to read this article.

If you found it helpful or interesting please let me know ???.